This paper introduces an approach to mapping relational database contents to ontologies. The current effort is motivated by the need of including into the Semantic Web volumes of web data not satisfied by current search engines. A graphical tool is developed in order to ease the mapping procedure and export enhanced ontologies linked to database entities. Moreover, queries using semantic web query languages can be imposed to the database through its connection to an ontology. Using Protégé, we were able to map ontology instances into relational databases and retrieve results by semantic web query languages. The key idea is that, instead of storing instances along with the ontology terminology, we can keep them stored in a database and maintain a link to the dataset. Thus, on one hand we achieve smaller size ontologies and on the other hand we can exploit database contents harmonizing the semantic web concept with current wide-spread techniques and popular applications.
It is a well known fact that the rapid evolution of the Internet has brought up significant changes to information management. The web of knowledge changed the way people share, access and retrieve data. The existing data that lie on the web offer a significant source of information for almost anything.
Search engines have been evolved and research has been conducted in order to exploit the web resources. Since Internet became a public common currency and mostly referred to as the World Wide Web, its content growth made the use of search engines a gateway to information. Without Google, Yahoo! or Altavista the web as it is today would be useless. Terabytes of data in millions of web pages are impossible to be searched without the use of special Information Retrieval (IR) techniques offered by the current search engine implementations.
Nevertheless, still much work needs to be done so as to render all this information
retrievable. It is well known that there is a large quantity of existing data on the web
stored using relational database technology. This information is often referred to as
the Deep Web [
The creator of the web, Tim Berners-Lee proposed the idea of the ‘Semantic web’
to overcome the handicaps referenced. As stated in [
The key role to this effort is played by ontologies. Their use aims at bridging and
integrating multiple and heterogeneous digital content on a semantic level, which is
exactly the point of the idea. Ontologies provide conceptual domain models, which
are understandable to both human beings and machines as a shared conceptualization
of a specific domain that is given [
Nevertheless, ontologies suffer from a scalability problem. Keeping large amounts of data in a single file is a practice with low efficiency. Ontologies should rather describe content than contain it. The application developed and presented in this paper introduces a solution to this problem. Current data is and should be maintained separately while ontologies can be developed in order to enhance its meaning and usefulness.
The paper is organized as follows: Section 2 provides the definitions of the aspects discussed in this paper. Section 3 details the mapping architecture, the mapping process and the integrity checks performed to assure consistent results. In Section 4 we present our case study and compare it to related efforts in Section 5. We conclude and discuss about future work in Section 6.
This section provides a background definition of our work. This will make clearer every aspect of the proposed idea.
Formally, an ontology can be defined as a model of a knowledge base (KB). The
main difference between an ontology and a KB is that the latter offers reasoning as an
addition to the model. Thus, it is not possible to extract implicit knowledge from the
ontology without the use of reasoning procedures. A KB created using Description
Logics comprises the two following components [
The first part contains all the concept descriptions, the intentional knowledge and is called Terminological Box (TBox). The TBox introduces the terminology, the vocabulary of an application domain. It can be used to assign names to complex descriptions of concepts and roles. The classification of concepts is done in the TBox determining subconcept/superconcept relationships between the named concepts. It is then possible to form the subsumption hierarchy.
The second part contains the real data, the extensional knowledge and is called Assertional Box (ABox). The ABox contains assertions about named individuals in terms of the vocabulary defined in the TBox. 2.2
According to [
In order to provide access to their contents, databases support many query languages, but SQL is the practical choice. SQL is powerful and provides various means of manipulating relational databases. The inputs and outputs of SQL queries are Relations. Queries are evaluated using instances of input relations (tables) and produce instances of output relations. SQL is said to be relationally complete – since it is a superset of relational algebra – meaning that every query that can be posed to a relational algebra can be expressed in SQL. In other words, with the use of SQL queries, there is no combination of subsets of tuples in a database that cannot be retrieved. 2.3
In a simplified point of view, we can compare the schema of a relational database to
the TBox of a KB and the instance to the actual data to the ABox. We could claim
that databases are similar to Knowledge Bases because of the fact that they both are
used to maintain models and data of some domain of discourse (UofD) [
In our work, we succeeded in mapping the relational database contents to the TBox
of the ontology. The description language chosen is OWL-DL [
What has been accomplished in the current work is to reference database tuples through the ontology TBox. Common approaches describe mapping mechanisms between ontology classes and database tables. Our enhancement from the scope of the Semantic Web lies on the fact that the mappings are capable of corresponding class individuals (alt. instances) to any possible dataset combination. From the view of database theory, we enriched the database schema structure to include description logics and answer queries on a semantic level.
There are significant differences between the knowledge bases and databases. Among the differences is the ‘open-world’ semantics in opposition to the ‘closed-world’ semantics that hold respectively for each one.
The relational database schema abides by the so called ‘closed world assumption’. The system’s awareness of the world is restricted to the facts that have been explicitly told to it. Everything that has not been stated as true fact is false. In a ‘closed world’, a null value about a subject’s property denotes the non-existence i.e. a null value in the ‘isCapital’ field of a table ‘Cities’ claims that the city is not a capital. The database answers with certainty because, according to the closed world assumption, what is not currently known to be true is false. Thus, a query like ‘select cities that are capitals’ will not return a city with a null value at a supposed boolean isCapital field.
On the other hand, a query on a KB can return three types of answers that are true, false and ‘cannot tell’. The ‘open world assumption’ states that lack of knowledge does not imply falsity. So a question in an appropriate schema ‘Is Athens a capital city?’ will return ‘cannot tell’ if the schema is not informed while a database schema would clearly state that ‘no’.
Class properties were not mapped to relations between database tables. The reason is that regarding the ontology semantics, the class hierarchy is fully different from the property hierarchy. Foreign key constraints involving relations, though, can be mapped to Object Properties linking OWL classes. This approach however, would not produce more powerful results; it would rather complicate reasoning checks. So, in the work that is presented here, concept integrity checks are being held only during the mapping process without being an extra burden to the resulting ontology. 3
In this chapter we clarify the architecture of the technique through which the target goal is reached. We describe the mapping process, analyze the integrity constraints and explain how the user can retrieve database data through the intermediate mapping ontology. 3.1
Our proposed mapping method consists of four steps. First, we capture data from the database. The data can be any combination of datasets. More particularly, the ability is given to select the desired subset of records belonging to various tables. In step two, we select a class of the ontology. Step three is the most important as all consistency checks are being performed in this step along with evaluation, validation and refinement of the mapping. In step four takes place the modification of the resulting ontology and the additional information is added to it. These four steps can be repeated as many times as required. By saving the mapping in a new ontology, additional information will be kept such as the database type and name, the initial ontology name and when the mapping is last modified.
The final result is the initial ontology enhanced to include references to datasets. These references will be under the form of class properties in the ontology, all assigned as value a string containing the actual SQL query that returns the dataset. Each query posed to the ontology will check the existence of the mapping property. In the case that it does not exist, the results are no affected. Otherwise, the results will be database entries instead of class individuals.
During the mapping process, tests are run to insure the concept’s consistency. These tests require enough computational time and are therefore computed once, responding with a positive or negative answer, informing the user in each case. Every time a new mapping is defined by the user, the following requirements must be met.
First of all, two disjoint classes cannot have mappings to the database that contain common records or subsets of records. Even in the case of finding a single datum in common, the mapping will be rejected. We note that ‘common data’ will as well be considered data that belong to different fields of two tables connected with a foreign key relationship. Disjoint classes cannot be mapped to records of these fields because a foreign key connects the two tables semantically. The classes’ disjointment does not allow such connections. This constraint reassures that the datasets will be as well disjoint. In addition, the same check is run respectively for the class’ sub- and superclasses.
Moreover, a check is performed to reassure that subclass hierarchy is maintained in the mapped data. More specifically, if a class A is subclass of a class B and the two classes are mapped to record sets R(A) and R(B) respectively, then R(A) must be a subset of R(B) as well. This check must hold recursively for every mapping statement. Special care is taken of table fields that have foreign key relationships. Subclasses can be mapped to field entries outside the domain of the superclass mapping as long as these fields are referred to by foreign keys. In conclusion, for a mapping to be accepted, the set of data for each class must be a subset of the class’ superclasses.
The checks are performed after each mapping command. The checks were intentionally not strict as the system was designed keeping in mind the final user: the domain expert who will produce the mapping result. Thus, only the necessary consistency checks were implemented balancing the user’s freedom with the concept’s integrity.
Our implementation includes the functionality of imposing queries by terms of semantic web query languages. Fig. 3 illustrates how the application handles user’s queries.
First, users’ queries are parsed and checked syntactically. The query would instantly return with the desired results but here is where the mapping intervenes. Instead of returning the class resources, for each class we check if there exists the mapping property. If the related property is found, the query is redirected to the database. The results are then formatted and served to the user.
The achievement lies in the fact that we added an extra layer of interoperability, between the application GUI and the actual data. This hybrid approach leaves the ontology and the actual data intact, only serving as a semantics addition to current systems. The generalization of the current concept to current web technologies is about to offer a semantic layer that will add the desired intelligence without modifying legacy systems.
Our implementation was built as a plug-in on top of the Protégé [
For a database backend, the VisAVis tool supports connections via JDBC to the MySQL and PostgreSQL database management systems.
As far as it concerns the Semantic Web query languages, several recommendations
have been considered. The issue is that query languages about OWL ontologies are
still in their infancy [
In this section, we give a practical example of the mapping method described above.
For our example’s purpose, we will use an OWL-DL ontology that can be found at
[
We have implemented the mapping method described in the previous section, as a Protégé tab plug-in, colorfully named as VisAVisTab and shown in Fig. 4. The first step is to open the ontology that contains the classes of interest. Then, we connect with the corresponding database that contains the real data. At that point, we can see both the ontology and the database hierarchy and we are able to select a set of data from the database using the application’s graphical user interface. In fact, the application constructs, in the background, an SQL query that, when executed, returns the desired dataset. This SQL query, and not the data set itself, will be correlated with a certain ontology class selected by the user.
To demonstrate VisAVis in action, we are using a database called ‘travel’ that contains among others the tables ‘cities’, ‘hotels’, ‘museums’ and ‘activities’. The table ‘activities’ contains information about activities offered to tourists, including its description and its type (surfing, hiking etc.). The activities’ types are stored in the ‘activity_type_id’ column, which is foreign key to the ‘id’ column of the ‘activities_types’ table.
A common approach would be to map the class ‘Activity’ of the OWL ontology to the columns ‘id’, ‘description’, ‘activity_type_id’ from the ‘activities’ table and to the ‘id’, ‘name’, ‘description’ columns of the ‘activities_types’ table. The data selection process is easily carried out by dragging the columns needed from the database hierarchy and dropping them into the ‘Desired Fields’ field. In order to map the class ‘Hiking’, which is a subclass of the ‘Activity’ class, we should add a condition that would enable us to select only the activities of the certain type. Likewise, the classes ‘Surfing’ and ‘Safari’, which are also subclasses of the ‘Activity’ class, could be mapped to the appropriate data that would satisfy the necessary conditions. The conditions can be applied to a certain set of columns by dragging the necessary column, dropping it to the ‘Conditions’ field and then, filling in the rest of the constraint. When the data selection has finished, the user can complete the mapping process by pressing the ‘Map!’ button.
It is worth mentioning that when columns from two or more tables are selected, our application includes in the SQL query an additional condition representing the referential integrity constraint. In other words, foreign keys are taken into account whether they are user-specified or not and added to the final SQL query. This happens even in the case where two or more tables have two or more distinct relations between them. For instance, for the following example a mapping concerning the class ‘Activity’ is the following:
Hiking -> Field(s): activities.description with condition(s): (activities_types.name=’Hiking’)
The corresponding SQL query, which is automatically generated by our SQL builder, is shown below in a snapshot of the enhanced ontology: <owl:Class rdf:about="#Hiking"> <queryString>SELECT activities.description FROM activities, activities_types WHERE (activities.activity_type_id=activities_types.id) AND (activities_types.name = "Hiking") </queryString> <rdfs:subClassOf>
<owl:Class rdf:about="#Sports"/> </rdfs:subClassOf> </owl:Class>
As we notice in the above sample, the mapping process has as a result the introduction of a datatype property to the class. The property is arbitrarily named ‘queryString’ and is given as domain the class’ domain and as value the corresponding SQL query. Thus, the initial OWL ontology is enhanced with additional properties that represent the mappings accomplished. Following the same course of actions, we can map the entire ontology to sets of data from the database.
We should also note that during the mapping process, consistency checks are executed in order to check whether mappings conform to the ontology rules or not as described in Section 3.2. For instance, if we tried to map to the class ‘Activity’ some data from the ‘hotels’ table, the mapping validator would reject this mapping as inconsistent with the ontology rules, since classes ‘Activity’ and ‘Accomodation’ are disjoint.
Finally, in order to test the whole mapping process, our application enables the execution of a semantic query, which will return actual data from the database, instead of ontology elements. As it has already been mentioned, a similar approach could be followed in a sophisticated Semantic Web search engine, that would first execute a semantic query and then, using mappings between concepts and sets of actual data or documents, it would return these sets of data or documents.
The Semantic Web is the new WWW infrastructure that will enable machine process of the web content and seems to be a solution for many drawbacks of the current Web. The semantic information addition to the current web will create a new information layer on top of the current technologies. Ontology to database mapping is an active research topic to this direction based on the observation that the web content is dynamic and most of it originates from databases. Several approaches have been presented aiming at semantic integration proposing techniques for database-toontology correspondence. Related work can be divided in two fields, database-toontology migration and database-to-ontology collaboration. Our approach belongs to the latter; hence similar work will be given reference in the current chapter.
The Ontomat Application Framework introduced in [
D2RMap was first presented in [
R2O [
The Unicorn workbench [
We have developed a novel, integrated and semi-automated approach for mapping and reusing large sets of data into the Semantic Web. Using the tool described above, it is possible to create a mapping between any relational database and any ontology. For the mapping to have a meaning, however, it is essential that the concepts described are at some point similar. For example, it has no meaning mapping a database containing a company’s customers to an ontology describing plants. The logical aspect is left to the judgment of the user.
The current version implements a rather small subset of the SQL language. The mapping to the actual data is in fact accomplished using ‘select from where’ functions. We are currently working on enriching the ontology result to include more functions such as ‘group by’ and ‘order by’. Functions such as max(), count() and avg() are not supported either, in the current version. Support needs to be added for several RDBMS such as Oracle or Microsoft SQL Server to cover a significant percentage of today’s choices. Yet, these topics are only implementation-specific and of no special research interest. They are however needed if the aim is to provide the Protégé plug-in the tool’s corresponding plug-in section.
An important open issue in the current implementation is also the fact that queries only return results from the database. The user should also be informed about class individuals, not only database records. The current development is not purposed to distinct between ontologies and databases; it is about offering a collaboration framework and an intermediate layer for database exploitation by Semantic Web applications.
The resulting enhanced ontology is subject to easy programmatic access. In addition, once the mapping result is created, our tool will only be needed in case of change of the database schema. Practice has proven that database schemas are not frequently changing. Our intention is to use such ontologies combined with software agents in order to create an intelligent environment where data search and retrieval will implement the Semantic Web concept: users will be able to search among large volumes of semantically annotated data.