Classical Business Intelligence (BI) solutions provide di erent means like OLAP, data mining or case based reasoning to explore structured data. The data is usually stored in dedicated repositories like data warehouses and then explored by standard BI means, which are usually based on mathematical statistics and provide a quantitative analysis of the data. In this paper, we complement this approach in two respects. First of all, FCA, as a qualitative approach for data analysis, is used for analyzing the data. Second, the analyzed data is not stored in a data warehouse, but in a triple store instead. To make this possible, the existing FCA-tool ToscanaJ has been extended in order to act on triple stores. The approach in this paper is exempli ed on a dataset of documents crawled from the SAP community network.
Business Intelligence (BI) solutions provide di erent means like OLAP, data mining or case based reasoning to explore data. In the standard BI approach, this data is usually extracted from transactional databases, transformed into a uni ed schema which is tailored to BI needs, and stored in a dedicated repository like a data warehouse. The standard BI means which are used to explore this data are focusing on attributes which can be numerically measured, thus they provide a quantitative analysis of the data (aka "number crunching") based on mathematical statistics. To some extent, though arguably oversimpli ed, one can understand BI as acting on lists or tables lled with numbers.
Compared to number crunching, Formal Concept Analysis (FCA) [
A general overview over the bene ts of FCA in information science is provided
by Priss in [
With respect to BI, FCA can be for example considered as a data mining
technology, particularly for mining association rules [
FCA targets a formalization of the philosophical understanding of concepts
with their extensions and intensions, thus FCA indeed is a semantic technology.
Though it does not belong to the core of Semantic Web technologies, FCA
provides decent means to de ne and analyze concept hierarchies, so it comes as no
surprise that FCA has been used in the realm of querying, browsing and
visualization of ontologies (e.g. OWLFCAViewTab for Protege and OntoViz), ontology
alignment (e.g. FCA-Merge and OntEx), ontology engineering (e.g. relational
exploration or role exploration) and ontology learning (e.g., Text2Onto).2 In this
paper, we exemplify the bene ts of FCA for (semantically enabled) BI by
analyzing data in a triple store with FCA methods. In order to do so, the existing
ToscanaJ tool has been modi ed such that it can retrieve data from triple stores
instead of relational databases. A short introduction into ToscanaJ and its
modi cations are provided in Sec. 3. An often named bene t of ST compared to
relational databases are the ST capabilities to better deal with unstructured
data like text-documents. FCA has already been employed to create concept
hierarchies out of the content of text documents, e.g. [
In this paper, we apply FCA on a dataset of documents crawled from the SAP community network3 (SCN), but do not target to investigate the contents of the documents, but utilize meta-data of the documents (which have been created in the crawling process) for FCA-purposes. This use case is described in Sec. 4. 2
FCA per se can only deal with binary attributes. For real data, the situation is usually di erent: Attributes assign speci c values (which might be strings, numbers, etc) to data. For example, RDF-triples (s; p; o) are exactly of this form: The attribute p - from now on we will use the RDF-term "property" insteadassigns the value o to the entity s. In FCA, a process called "conceptual scaling" 1 http://toscanaj.sourceforge.net 2 As this eld is only weakly related to this paper, no references are given. 3 http://www.sdn.sap.com/irj/scn/index is used to deal with this issue. As ToscanaJ heavily uses scales, we recapitulate their core notions.
Let a speci c property be given with a set of possible values. A conceptual scale is a speci c context with the sex age values of the property as formal objects. The choice of Adam m 21 the formal attributes of the scale is a question of the Betty f 50 design of the scale: The formal attributes are meaningful Chris 66 attributes to describe the values; they might be di erent Dora f 88 entities or they might even be the values of the property Eva f 17 again. To exemplify conceptual scaling, we reuse a toy Fred m example from [18], which is the following table provided George m 90 on the right with two many-valued properties "sex" and Harry m 50 "age". Note that empty cells are possible as well.
Next, two conceptual scales for the properties "sex" and "age" and their line diagrams are provided.
S1 m f m f
With the conceptual scales, the initial many-valued context can be
transformed into a standard context, so that the corresponding concept lattice can be
displayed. In [
For conceptual scales, the following two points should be noted:
1. There is usually no standard or even necessary interpretation of an attribute:
It has to be decided by the eld expert which scale is appropriate. As
discussed in [
Both points are important for ToscanaJ, which is discussed in the next section. 3
There is a variety of software for FCA available. Most of them support the creation of contexts from scratch and the subsequent computation and display of the corresponding concept lattices. Contrasting this approach, Elba and ToscanaJ are a suite of mature FCA-tools which allow to query and navigate through data in databases. They are intended to be a Conceptual Information System (CIS). CISs are "systems that store, process, and present information using concept-oriented representations supporting tasks like data analysis, information retrieval, or theory building in a human-centered way." Here, a CIS is an FCA-based system used to analyze data stored in one table of an RDBMS.
Similar to other BI-systems, in CIS we have to distinguish between a design phase and a run-time-phase (aka usage phase), with appropriate roles attached to the phases. In the design phase, a CIS engineer (being an expert for the CIS) together with a domain expert who has limited knowledge of a CIS) develops the CIS schema, i.e. those structures which will be later on used to access the system. This schema consists of manually created conceptual scales. Developing the scales is done with a CIS editor (Elba) and usually a highly iterative process. In the run-time phase, a CIS browser (ToscanaJ) allows a user to explore and analyse the real data in the database with the CIS schema. The diagram in Fig. ref g:ElbaToscanaJWork ow depicts this overall work ow.
From the author's point of view, ToscanaJ is that tool which allows best (if only) to apply a BI-like approach to analyze data with FCA-methods, thus {to some extent{ it comes closest to the envisioned CUBIST-system (though the envisioned CUBIST-system will provide di erent functionalities than ToscanaJ). Anyhow, the original Ebla/ToscanaJ-suite has been developed to analyze data in a relational table, i.e. a table in a RDBMS or an excel- le. We have extended the suite in order to be able to access data in a triple store. The reasons for doing so are twofold: { On the one hand, with the extended version of ToscanaJ we have a rst FCA-system which is capable to apply FCA-based visual analytics on top of a triple store. { On the other hand, analyzing the pros and cons of ToscanaJ w.r.t. the envisioned CUBIST-system will help to develop a CUBIST prototype which will overcome the shortcomings (with respect to BI-applications) of existing FCA-tools. This extended version of the suite uses the Sesame framework4 for accessing a triple store and and querying the RDF data therein. It provides two ways of connecting to a triple store over Sesame. One of them is over HTTP via Apache Tomcat5, the other one is over the SAIL API6. Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies by the Apache Software Foundation. The SAIL API (Storage And Inference Layer) is a low level system API for RDF stores and inferencers. It is used for abstracting from the storage details, allowing various types of storage and inference to be used.
In a triple store we do not directly have the notions of tables and columns like in databases. As table information we use the type information in the triple store: we treat the objects of triples with the predicate rdf:type as tables. As column information, we use the predicates relating the subjects of the selected type to any object. More precisely, in order to detect the columns we get those subjects of the selected type and retrieve all distinct predicates that relate these subjects to an object.
The Elba/ToscanaJ-suite provides di erent kinds of conceptual scales. We have extended three of them {namely nominal scales, attribute scales and context tables{ in order to act on triple stores.
Nominal scales are the simplest type of scales one can automatically create in Elba. They are used for properties like gender or country with mutually exclusive values. The formal attributes of the nominal scale are selected values of that property. As each object is assigned at most one of these values, the attribute concepts form an anti-chain, thus the scale cannot reveal any insight into attribute dependencies. 4 see http://www.openrdf.org/doc/sesame2/system 5 see http://tomcat.apache.org/ 6 see http://www.openrdf.org/doc/sesame2/system/ch05.html
Attributes scales o er an attribute-centered view, being close to "classical" formal contexts and allowing to create complex scales in an intuitive manner. Here each attribute is a property-value pair, which is manually selected from the triple store. Moreover, the CIS engineer can choose between a) "use only combinations existing in the database" and b) "use all possible combination". For option a) the diagram will only consist of concepts that could be derived from the data in the triple store, thus the diagram will reveal insights into dependencies between property-value pairs. If b) is chosen, a diagram of a Boolean lattice of all listed property-value pairs will be created independently of whether there exists objects in the triple store for each property-value combination or not.
Context table scales o er the most freedom to the CIS engineer. In context tables, arbitrary labels act as formal attributes. In contrast to the last two types of scales, no property-value pairs are chosen as attributes, thus now it has explicitly to be speci ed which objects of the data set ful l the formal attributes. This is done by entering SPARQL expressions, which act as formal objects, and by entering the incidence relation as well, i.e. the relation which here relates the formal objects (SPARQL expressions) to the attributes (labels). 4
In order to evaluate our approach, we have used a dataset crawled from the SAP Community Network (SCN). SCN contains a number of forums for SAP users and experts to share knowledge. Our dataset is taken from the forum ServiceOriented Architecture (SOA), which contains 2600 threads and 10076 messages. The dataset is annotated by the crawler using ontologies from the NEPOMUK project. The used ontologies and short descriptions7. are provided below. { NEPOMUK Information Element Ontology (NIE): The NIE Framework is an attempt to provide uni ed vocabulary for describing native resources available on the desktop. { NEPOMUK le ontology (NFO): The NFO intends to provide vocabulary to express information extracted from various sources. They include les, pieces of software and remote hosts. { NEPOMUK Message Ontology (NMO): The NMO extends the NIE framework into the domain of messages. Kinds of messages covered by NMO include Emails and instant messages. { NEPOMUK Contact Ontology (NCO): The NCO describes contact information, common in many places on the desktop.
From these ontologies, our dataset uses the following classes as types: { nie#DataObject: A unit of data that is created, annotated and processed on the user desktop. It represents a native structure the user works with. This may be a le, a set of les or a part of a le. { nfo#RemoteDataObject: A le data object stored at a remote location. 7 taken from the project website http://www.semanticdesktop.org/ontologies { nie#InformationElement: A unit of content the user works with. This is a superclass for all interpretations of a DataObject. { nco#Contact: A Contact. A piece of data that can provide means to identify or communicate with an entity. { nmo#Message: A message. Could be an email, instant messanging message, SMS message etc.
For analyzing experience levels of the users of the SOA forum, we used the Contact type above and created a scale based on the number of posts, number of questions, number of resolved questions information provided in the data. We have named users that have less than 50 posts as newbie, users that have more than 400 posts as frequent, users that have more than 1000 posts as pro . Note that by de nition, every pro is a frequent user as well, but no one can be both newbie and frequent (or pro ) user. Moreover, we label users that have asked more than 200 questions as curious and people that have resolved more than 300 questions as problem solver. Note that this scale uses di erent measures (number of posts, number of questions, numbers of answers). In Fig. 2 it is shown how the context table in Elba is used to create the appropriate scale, and in Fig. 3 we see in Elbe the corresponding lattice. Note how SPARQL-queries are utilized to describe set of objects.
Next, for analyzing experience levels based on the number of points information we created another scale. This time, as labels we took contributor types that are o cially de ned by SCN as bronze, silver, gold and platinium contributors, which have more than 250, 500, 1500 and 2500 points respectively. Of course, there might be persons who do not have any of these "medals" at all. We have two possibilities to understand the medals, as depicted in Fig.4.
The two approaches for modelling the scales shall be exempli ed with gold owners. A gold owner has at least 1500 points. Either we consider a gold owner to be a silver owner and bronze owner as well (as he has more than 500 points to reach silver status and more than 250 points to reach bronze status), or we consider him to be not a silver or bronze owner (that is, a gold owner has between 1500 and 2499 points). Thus the two scales in Fig. 4 capture the di erent notions (aka meanings or semantics) of the status.
Besides these three scales, more scales have been created in Elba, which are not described here due to space limitations. We show next how the scales are utilized in ToscanaJ. First, in Fig. 5 and Fig. 6, we show how the diagrams we have created in Elba now appear with actual numbers in ToscanaJ.
The above displayed concept lattices are separately informative about the properties of forum users, i.e., the rst one about experience levels based on number of posts, questions and resolved questions, and the second one about number of points. One of the most powerful techniques of FCA is to \combine" such lattices to give a combined view of several lattices together, which is called a nested line diagram. In its simplest form, a nested line diagram is a concept lattice whose concepts are themselves also concept lattices. Nested line diagrams allow the user to select a concept and zoom into it to see the lattice nested in that concept. quite natural. On the other hand, the one pro user with no medal is a surprising outlier which might deserve a dedicated investigation. In ToscanaJ, and thus in our extension of it to triple stores, one can nest an arbitrary number of diagrams and can browse nested diagrams easily by zooming in and out. 5
This paper has shown how FCA can be applied data analysis methodology for data in triple stores, and the existing ToscanaJ suite has been extended in order to act not only on relational databases, but on triple stores as well.
As scales in the ToscanaJ work ow are manually crafted in the design phase of a CIS, this work ow is feasible for stable schemata. For ST, this is usually not the case: here the paradigm of agile schema development is prevalent. We plan to implement automatic or at least semi-automatic generation of scales based both on the schema information and the actual data in the triple store.
As stated in the introduction, FCA should be understood to complement existing BI approaches. ToscanaJ utilizes scales, thus lattices, for all kind of data, even for numerical attributes (which can be modelled as ordinal scales) and nominal attributes. The lattice structure of the scales do not reveal any structural insights, only the distribution of objects amongst the lattice nodes is interesting. Thus it can be argued that for these types of attributes, the standard visualization of BI like pie or bar charts are more appropriate. For this reason, another future research direction of CUBIST is the development of hybrid solutions, combining "classical" BI with FCA. This covers combinations of scales and their diagrams with BI diagrams for numerical data, like pie charts or sun-burst diagrams, and compared to nesting of scales, di erent approaches for using simultaneously several scales. In the long run, CUBIST intends to combine visualizations for both quantitative and qualitative analytics.
Disclaimer: Parts of this work have been carried out in the CUBIST project, which is funded by the European Commission under the 7th Framework Programme of ICT, topic 4.3: Intelligent Information Management. 16. G. Stumme, R. Wille, and U. Wille. Conceptual knowledge discovery in databases using formal concept analysis methods. In J. M. Zytkow and M. Quafofou, editors, Proceedings of the 2nd European Symposium on Principles of Data Mining and Knowledge Discovery (PKDD'98), volume 1510 of Lecture Notes in Arti cial Intelligence, pages 450{458. Springer-Verlag, 1998. 17. F. Vogt and R. Wille. Toscana | a graphical tool for analyzing and exploring data. In R. Tamassia and I. G. Tollis, editors, Graph Drawing, pages 226{233.
Springer-Verlag, 1995. 18. K. E. Wol . A rst course in formal concept analysis. In F. Faulbaum, editor, Proceedings of Advances in Statistical Software 4, pages 429{438, 1993.