General purpose query interfaces to relational databases can expose vast amounts of content to the Semantic Web. In this paper, we discuss Automapper, a tool that automatically generates data source and mapping ontologies using OWL and SWRL. We also describe the use of these ontologies in our Semantic Distributed Query architecture, an implementation for mapping RDF queries to disparate data sources, including SQL-compliant databases, using SPARQL as the query language. This paper covers Automapper functionality that exploits some of the expressiveness of OWL to produce more accurate translations. A comparison with related work on Semantic Web access to relational databases is also provided as well as an investigation into the use of OWL 1.1.
A wealth of information resides in relational databases, which are highly
engineered for scalability, transaction management, security and access by
existing applications [
The paper presents one such tool, Automapper, and is organized as follows:
Sections 2 and 3 describe both Automapper and the overall architecture in which
Automapper operates. Section 4 discusses the current use of OWL and Section 5
details the current use of SWRL. Section 6 provides a simple application of
Automapper and the Semantic Distributed Query architecture. Section 7 covers
related work. Section 8 explores how the new features in OWL 1.1 can be used to
enhance Automapper. Finally, Section 9 concludes with future directions.
provided. While that is not the focus of this paper, a general understanding is
necessary to appreciate Automapper's role in the system as a whole. As shown in
Figure 1, Automapper is part of a larger system for decomposing a SPARQL
query, expressed using a domain ontology, over multiple data sources and
merging the corresponding data into a single result set [
SBRD uses both Automapper artifacts to correctly map a SPARQL query
expressed using the data source ontology into SQL SELECT statements. Database
query result sets are mapped back into the data source ontology and returned to
SQD. As a final step, SQD recombines the various result sets, maps the data into
the domain ontology and returns this data to the user. Automapper was developed
in Java and needs to be run only once against a given relational database to
automatically generate both the data source ontology and the mapping data. Using
the method java.sql.Connection.getMetaData(), we are able to mine the necessary
table definitions such as column names, primary keys, foreign keys, remarks and
type declarations to generate the data source ontology. Automapper constructs
these artifacts based on a configuration file, which contains instance data based
on a simple configuration ontology. This ontology permits additional primary
and foreign key information, the option to include or exclude comments in the
mapping instance data, the capacity to limit the visibility of specific tables and the
ability to override a declared column datatype with another XML Schema
datatype [
While SQD relies on SWRL rules for mapping, SBRD depends on Automapper's
generated mapping data. SBRD employs these mappings for transforming
SPARQL data source queries into SQL queries for data retrieval. Our mapping
ontology, based on the mapping ontology used by D2RQ [
Use of OWL
The following class descriptions, axioms and restrictions are currently generated by Automapper: 1. maxCardinality is set to 1 for all nullable columns 2. cardinality is set to 1 for all non-nullable columns 3. All datatype and object properties that represent columns are marked as FunctionalProperties. To ensure global uniqueness and class specificity, these properties are given URIs based on concatenating the table and column names 4. allValuesFrom restrictions reflect the datatype or class associated with each column 5
Automapper generates SWRL rules to identify identical individuals based on their
primary key values. These rules use swrl:SameIndividualAtom
statements to express class-specific inverse functional relationships, including
those involving multiple properties (primary key columns), neither of which is
directly supported by OWL [
Assume a simple OWL domain ontology of personnel information used by a human resources department. This ontology defines classes Person and Dept and datatype properties gender, name, code and projectName1. It also defines an object property, department, used to associate a Person with a Dept. A Dept is uniquely identified by its code. Below is a fragment represented in Turtle: :Person a owl:Class; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :name ; owl:maxCardinality
"1"^^xsd:nonNegativeInteger ], [ a owl:Restriction ; owl:onProperty :name ; owl:allValuesFrom xsd:string ], [ a owl:Restriction ; owl:onProperty :department ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ], [ a owl:Restriction ; owl:onProperty :department ; owl:allValuesFrom :Dept ] . :Dept a owl:Class; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :code ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ], [ a owl:Restriction ; owl:onProperty :code ; owl:allValuesFrom xsd:int ] .
A domain model will often incorporate data from multiple databases but not all
terms defined in a data source ontology will map to the domain ontology. For the
sake of brevity, we limit our example to a single database (hresources) that holds
staffing information; Tables 1 and 2 list the contents of the Staffing and
Departments tables, respectively. Note that the Department ID column is only
partially dependent on the primary key (an employee belongs to one department,
independent of a project) and therefore the table is not in second normal form [
1 The association between Person and a Project could also be appropriately modeled using an object property.
From this schema, Automapper creates the data source ontology and classspecific inverse functional rules, of which fragments are listed below: dsont:Hresources.Departments a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty dsont:hresources.departments.id ; owl:allValuesFrom xsd:decimal ], [ a owl:Restriction ; owl:onProperty dsont:hresources.departments.id ; owl:cardinality "1"^^xsd:nonNegativeInteger ] . dsont:Hresources.Staffing a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty dsont:hresources.staffing.name ; owl:cardinality "1"^^xsd:nonNegativeInteger ], [ a owl:Restriction ; owl:onProperty dsont:hresources.staffing.name ; owl:allValuesFrom xsd:string ], [ a owl:Restriction ; owl:onProperty dsont:hresources.staffing.deptid.Object ; owl:cardinality "1"^^xsd:nonNegativeInteger ] . dsont:Hresources.DeptsSame a ruleml:Imp ; ruleml:body
( [ a swrl:ClassAtom ; swrl:argument1 :A ; swrl:classPredicate dsont:Hresources.Departments ] [ a swrl:ClassAtom ; swrl:argument1 :B ; swrl:classPredicate dsont:Hresources.Departments ] [ a swrl:DatavaluedPropertyAtom ; swrl:argument1 :A ; swrl:argument2 :Var0 ; swrl:propertyPredicate dsont:hresources.departments.id ] [ a swrl:DatavaluedPropertyAtom ; swrl:argument1 :B ; swrl:argument2 :Var0 ; swrl:propertyPredicate dsont:hresources.departments.id ] ) ; ruleml:head ( [ a swrl:SameIndividualAtom ; swrl:argument1 :A ; swrl:argument2 :B ] ) .
The corresponding mapping data is also generated. Below are two datatype property bridges, an object property bridge (representing a foreign key) and a class map all relating to the Departments table: :HRESOURCES.DEPARTMENTS.ID a map:DatatypePropertyBridge; map:column "ID"; map:datatype xsd:decimal; map:language "en"; map:property
dsont:hresources.departments.id . :HRESOURCES.STAFFING.DEPTID.OBJ a map:ObjectPropertyBridge; map:constraint [ a map:KeyConstraint; map:objectColumnOperand "ID"; map:operator :EqualsOperator; map:subjectColumnOperand "DEPTID" ]; map:objectClassMap
dsont:Hresources.Departments; map:property
dsont:hresources.staffing.deptid.Object . :Hresources.Departments a map:ClassMap; map:datatypePropertyBridge :HRESOURCES.DEPARTMENTS.ID, :HRESOURCES.DEPARTMENTS.NAME; map:table "DEPARTMENTS";
In the final step, we create SWRL rules to map between the data source and domain ontologies to enable SPARQL query decomposition and reconstitution. Below are sample rules used for mapping the data source Departments class to the domain ontology Dept class including the department ID: :RuleDeptClass a ruleml:Imp ; ruleml:body ( [ a swrl:ClassAtom ; swrl:classPredicate
dsont:Hresources.Departments ; swrl:argument1 :d ] ) ; ruleml:head ( [ a swrl:ClassAtom ; swrl:classPredicate domont:Dept ; swrl:argument1 :d ] ) . :RuleDepartmentCode ruleml:body ( [ a swrl:ClassAtom; swrl:classPredicate
dsont:Hresources.Departments ; swrl:argument1 :d ] [ a swrl:DataValuedPropertyAtom ; swrl:propertyPredicate
dsont:hresources.departments.id ; swrl:argument1 :d ; swrl:argument2 :c ] ) ; ruleml:head ( [ a swrl:DataValuedPropertyAtom ; swrl:propertyPredicate domont:code ; swrl:argument1 :d; swrl:argument2 :c ] ) .
Running the following query for the names of all people in department 1 and their associated project names: PREFIX : <http://example.org/2007/08/domain-ont#> SELECT ?pName ?name WHERE { [ a :Person ; :projectName ?pName ; :name ?name ; :department ?d ] .
?d :code 1 } yields: Alpha MattF, Alpha DaveK, Beta MattG, Beta DaveK.
Various tools have been developed to provide Semantic Web interfaces to
relational databases, including D2RQ, Gnowsis [
We initially used D2RQ and incorporated several modifications which we submitted to the D2RQ development team2. The changes involved query optimizations such as eliminating duplicate table prefixing, increased selectivity of property bridges (to limit the desired number of tables in a query), and SQL SELECT query partitioning for smaller queries. As SQD became more sophisticated, we determined that SBRD and other Semantic Bridges did not require the full power of D2RQ.
Automapper corresponds to D2RQ's generate-mapping3 script. It
continues the D2RQ use of instance data for SPARQL-to-SQL mappings, entity
concepts (e.g. ClassMap, uriPattern) and separate datatype and object property
bridges. Object property bridges more precisely model foreign key relationships,
although our model is not the only possibility [
OWL 1.1
The continued progress of of the W3C OWL Working Group provides an exciting
preview of the new features in OWL 1.1, many of which can be used to enhance
the functionality and expressivity of Automapper. The submission [
New Description Logic Constructs While many of the new description logic constructs are generally useful, only one can be automatically derived from relational database schemas, the IrreflexiveObjectProperty. Reflexive relationships involve the same instance as both the subject and object of the relation. Consider the example found above in Table 1. Suppose a new column was added, “Manager”, that was a foreign key to the “Name” column. The referential integrity constraints of a 2http://sf.net/mailarchive/message.php?msg_id=1143734217.12135.8.camel@localhost 3http://sites.wiwiss.fu-berlin.de/suhl/bizer/D2RQ/spec/#commandline relational database system would guarantee that someone’s manager must already be defined in the same table. Often, an additional constraint would be placed on this foreign key to prevent someone from being their own manager. However, OWL 1.0 cannot express this concept with a simple object (or functional object) property. The IrreflexiveObjectProperty in OWL 1.1 provides the ability to state that any given instance cannot be related to itself. In many cases, the irreflexivity of a database relation can be determined in an automated fashion and therefore this would be a valuable enhancement to Automapper. However, in cases where the irreflexivity cannot be automatically deduced, manual intervention can augment the generated OWL.
It is worth noting that many of the concepts represented by the other new property constructs are used in relational database systems in functions and stored procedures. While, these database concepts cannot be readily mapped in an automated fashion, an analyst using Automapper with knowledge of the existing database could take advantage of the new property constructs after the automated process has completed. 8.2
Expanded Datatype Expressiveness
OWL 1.1 allows the definition of user-defined datatypes. Specifically, the
working group’s specification document [
New OWL-DL Sub-Species While not directly affecting Automapper, as an application in the relational database OWL space, it is worthwhile to briefly call out DL-Lite which is specifically designed to provide the minimum expressivity required to meet the needs of modeling a relational database system. DL-Lite provides several performance gains over complete OWL DL; most notably it reduces data complexity, the complexity measured with respect to the number of facts in the ontology, from an NP-Hard problem to a LOGSPACE problem. Thus, Automapper should produce OWL that is restricted to DL-Lite. 9
We are currently applying Automapper's approach to other Semantic Bridges. Specifically, we are exploring its use for both SOAP and RESTful services in our Semantic Bridge for Web Services (SBWS).
Currently, URIs returned by SBRD are unique but generally not resolvable.
We intend to address this issue in future versions by generating resolvable URIs
and incorporating the best practices of the Linking Open Data initiative [
To the best of our knowledge, we believe that our rules and their usage are consistent with the design goals of the DL Safe SWRL Rules task force4. Decidability is a critical aspect of our architecture and is therefore focused on features such as the use of Horn rules with unary and binary predicates. We will continue to monitor the task force’s progress and incorporate necessary modifications. The advantages of SWRL built-ins have also proven essential. It is our hope that they are addressed in the DL Safe task force and will be comparable to the built-ins provided by SWRL.