The UNESCO convention on Intangible Cultural Heritage (ICH) requires countries to document their oral traditions, performing arts, traditional festivities, and so forth. Several institutions gather ICH, traditionally by hand, and record and disseminate it through conventional information systems (static knowledge in relational databases, RDB). Two di culties are that (1) review/re nement of their underlying database schemata by domain experts becomes disruptive, and (2) contribution from community, non-expert users becomes hard, even impossible. This article presents an interactive tool that implements a recent technique to perform Knowledge Discovery in Databases (KDD) guided by Formal Concept Analysis (FCA). The tool takes an RDB schema (in SQL), translates it into a formal context and later in a concept lattice using the CORON platform, allows domain experts to manipulate it and produces a formal ontology (in RDFS). Later, the ontology can be used to instantiate a semantic wiki as community collaboration tool, for example. The technique and tool are illustrated with an example from the ICH domain, using Chile's Culture Ministry online data. The tool is also available online.
The Chilean National Council of Culture and Arts1 (CNCA) has undergone the mission of documenting the ICH of di erent areas of the country in the context of a world-wide UNESCO2 convention to incentive the states parties 3 and NGOs to properly maintain their cultural knowledge. Considering the dynamic structure (data, concepts and relations) of this domain, the conventional information management systems should be su ciently exible in order to support changes and community collaboration such as well-known wikis [5]. For these reasons, CNCA needs a tool that allows to simplify the process of re nement of their current relational database model. KDD emerged as a tool to support humans 1 http://cultura.gob.cl 2 United Nations Educational, Scienti c, and Cultural Organization 3 http://whc.unesco.org/en/statesparties/ in the discovery and extraction of knowledge from large collections of data (usually stored in databases) where a manual approach for such task is very di cult (or nearly impossible) [3]. Thus, the human-centered nature of the approach is a key factor in any KDD process [1] since it has to ensure that knowledge is not only successfully found, but also understood by the nal user. For this reason, FCA proved to be a good support for a KDD process given its two-folded manner of representing knowledge, i.e. as concepts containing an extent (instances of the concept) and an intent (the attributes of the concept) [8]. To stress this fact, we quote [7] in the relation of FCA and KDD: \the process of concept formation in FCA is a KDD par excellence". FCA has been used to support KDD in several tasks for di erent domains. For example, [4] states that nearly 20% of the papers in the FCA domain consist on knowledge discovery related approaches. Furthermore, in [2] FCA is presented as the cornerstone of Conceptual Knowledge Discovery in Databases (CKDD) described as a human-centered process supporting the visual analysis of a conceptual structure of data for a given context of information. Since the principal di culty of CNCA (reviewing and re nement of ICH model) are rooted in a database schema analysis and amelioration which heavily requires human domain expertise, we rely on a CKDD tool to redesign the data schema already in use and to elicit an ontological schema from it.
In this article, we show a tool that implements an iterative and humancentred approach based on KDD and FCA. This method uses the concept lattice generated as a support for guiding the redesign process, considering the relevant knowledge of experts. This approach was proposed in an earlier work [6], however applies it in a web-based tool that allows any user work with his own schema.
The reminder of this article is organized as follows: Section 2 resumes the method proposed, Section 3 describes in detail the principal functionalities of the tool developed, Section 4 outlines an example for validating the tool with a domain expert. Finally, Section 5 presents a discussion on future work and concludes the paper. 2
The rst step starts by extracting the database schema and ends when it is
converted to a formal context. This step consists of three tasks: (
Formal context with user feedback
Data Database database Preprocessing schema formal context
Formal Concept
Analysis concept lattice formal context
Interpretation ontological Knowledge base schema tasks Schema processing Attribute integration Relational Attribute scaling
tasks Extensional stability calculation Attribute-concepts identi cation
tasks Question creation/answering Modularization
Ontological schema creation
This step receives a formal context and ends when a concept lattice is
constructed. The tasks performed are: (
Relational data schema model: A relational schema S = fR1; R2; :::; RjSjg is de ned as a set of tables or \relation schemas" Ri(A1; A2; :::; An) consisting of a table name Ri and a list of elds Aj which are value assignments of the domain dom(Aj ) to an entry in the table. The notation Ri:Aj stands for the eld Aj in table Ri.
This task is also interactive allowing the user to take most of the decisions w.r.t. how the ontological schema should be created. In the following, we refer to cnca: as the pre x used for the schema to be created.
Top Concept > = (S; S0): All tables are modelled using the resource description framework schema (RDFS) element rdfs:Class by default (e.g. cnca:Agent a rdfs:Class). The user may choose to annotate some of them with the element rdfs:Resource. For the set of attributes in S0, we provide a list of properties from RDFS and the dublin core ontology 4 where the user can select mappings going from the attributes to the ontology. For example, the attribute name is mapped to the property rdfs:label. The special attribute id is disregarded as its value in each entry is only considered to create a unique an valid URI 5.
Bottom Concept ? = (A0; A): All elds in A are modelled according to their nature: relational, non-relational attributes or special attributes. { Regular attributes are modelled by default using the rdfs:Property while the cnca: pre x is added to its name (e.g. cnca:establishment a rdfs:Property ). In addition, the range of the property is set to rdfs:Literal (e.g. cnca:establishment rdfs:range rdfs:Literal). { Relational attributes of the form related to:table are modelled with rdfs:Property and the range is set to the table they refer to. Additionally, the user is asked to rename the relation (e.g related to:Agent is modelled as cnca:participant 4 http://www.w3.org/wiki/Good_Ontologies#The_Dublin_Core_.28DC.29_ ontology 5 Universal resource identi er.
a rdfs:Property; cnca:participant rdfs:range cnca:Agent ). While the user may also be requested to create the inverse property, this feature is not available in RDFS and for the sake of simplicity we have disregard the use of OWL for now. { Special attributes of the form domain:Label are modelled di erently. For each di erent domain:Label we create a resource cnca:Label a cnca:Domain where cnca:Domain a rdfs:Class (e.g. cnca:People a cnca:Domain). A single property cnca:in domain a rdfs:Property; rdfs:range cnca:Domain; rdfs:domain rdfs:Class is created to annotate classes created from tables.
Attribute concepts Ai = (A0i; A0i0): For each attribute concept, we use its extent to set the domain of the already modelled properties in its intent creating cnca:Ai rdfs:domain cnca:R for all R 2 A0i (e.g. cnca:participant rdfs:domain (cnca:Festive Event,cnca:Ritual)). For the special attributes of the form domain:Label, objects are annotated using cnca:R cnca:in domain cnca:Label for all R 2 A0i (e.g. cnca:Agent cnca:in domain cnca:People).
There are some other actions taken during modelling, however for the sake of space and simplicity we do not discuss these in here. 3
The web-based tool intended to construct an ontological schema for a speci c
SQL relational database schema is compound of two principals components: (
Technology
This tool was developed on Python 2.7 and Flask micro-framework6. For
developing the following technologies are used, namely: SQLAlchemy ORM7 to connect
Python to the DB schema, python concepts8 to translate the DB schema to a
formal context for the rst time. Also we used the Coron Platform9 to
calculate the concept lattices and their extensional stabilities in order to identify the
attribute concept in each iteration. RDFLib10 was used for working with RDF
les in Python. At this moment, the tool is available in http://dev.toeska.
cl/rstanley/rdb2ontology. Once there, you can create a user account and
connect it with your own MySQL DB schema.
6 Flask http://flask.pocoo.org/
7 Python Object Relational Mapper (ORM) http://www.sqlalchemy.org/
8 Concepts: a python library for Formal Concept Analysis https://pypi.python.org/
pypi/concepts
9 Coron System: a symbolic data-mining platform http://coron.loria.fr/site/
index.php
10 RDFLib https://github.com/RDFLib/rdflib
To provide a way to modify the underlying formal context for the domain expert
we implemented some functionalities that can be looked at in gure 2. These
actions are divided in two groups named general options group marked with #1
and attribute-speci c options marked with #2. They are available for the domain
expert in each iteration. Firstly, the general options group is composed by (
The database schema of CNCA11 includes nearly 100 tables, however, for this example we have selected only 24 tables representing multi-disciplinary knowledge. These tables contain 24 objects, 53 attributes, and 13 relational attributes. The database schema for this example represents descriptions of agents, collective agents, festive events, culinary manifestations, geolocations and more. Figure 3 depicts the concept lattice obtained from the formal context generated by the 11 Chilean National Council of Culture and Arts database schema. Table 2 shows the decisions taken by the domain expert during 14 iterations. These decisions are based on question answering, domain labeling (modularization) or stoping the iterations. Figure 4 illustrates the nal concept lattice presenting the re ned structure after 14 iterations of the domain expert. We can distinguish several modules of information that have been marked. The expert called these modules as ICH subdomains identi ed from left to right, namely: Festive Event descriptors subdomain, Agent descriptors subdomain, ICH inventory subdomain, Culinary descriptors subdomain, Geographical subdomain, Photo subdomain. 5
To conclude, in this article we have presented a web-based tool fully functional based on an approach published in a previous work [6]. In this earlier work a case study was exposed obtaining interesting results, however these results were obtained executing calls to CORON platform in a manual way with the intervention of a knowledge engineer. The di erence between the previous work and this work is that the tool allows a domain expert to get an ontological schema himself in RDFS. In the example showed in section 4 we obtained 14 iterations from a similar excerpt of a database schema, however in the previous case study executed in [6] we obtained 9 iterations, so the resulting concept lattices were very similar. In each lattice the same modules were found, however, the time to reach the same result was higher. We have to consider that the expert used the tool without the assistance of a knowledge engineer. Currently, we are implementing the next step of this tool related to construct a semantic wiki based on the ontological schema. So even though the ontology obtained was simple, the domain expert could enrich it by using annotations in a semantic wiki. Also, this wiki could aid a domain expert in order to collaborate in the documenting process.