Experiences from a TBox Reasoning Application: Deriving a Relational Model by OWL Schema Analysis Thomas Hornung1 and Wolfgang May2 1 Institut für Informatik, Universität Freiburg, hornungt@informatik.uni-freiburg.de 2 Institut für Informatik, Universität Göttingen, may@informatik.uni-goettingen.de Abstract. Given an OWL-DL ontology of an application domain, we derive an application-specific relational model as known from classical database design, where the relational model is created from an ER model. The mapping depends as usual on the cardinalities of properties; namely whether a property is functional or not on a certain domain. In particular, since properties may be defined for several classes, where they can be functional on some of them, and multivalued on others, a detailed schema inspection is necessary. We show that this requires the definition of auxiliary classes at processing time followed by contain- ment checks. Thus, the process cannot be implemented declaratively by a simple set of SPARQL queries, but requires the use of a procedural framework that interferes with the ontology. 1 Introduction OWL Ontologies (sometimes) provide comprehensive knowledge about the con- cept level of an application: characterizations of the classes of relevant resources, the class hierarchy, properties, and relationships between them. Such information can be used, e.g., for designing a relational storage schema. The relational model provides a well-established and well-supported tech- nique for storing and accessing data. As a fully-structured data model, it is ap- plicable for applications where the schema is known, and where the data is rather homogeneous, in contrast to semistructured data models like XML or RDF (as logical data models), or column stores (as a physical data model). SPARQL queries can then be translated into equivalent SQL queries over the relational storage, which is part of the future development of this work; additionally, the data is accessible by SQL. Using traditional ER diagrams, the generation of a relational schema is rather simple: the classes are explicitly given with their attributes and relationships, and even only rarely, a simple class hierarchy is used. In contrast, an ontology is usually more complex, building on a richer class hierarchy. Thus, deriving the relational model cannot be done by only looking up attributes and relationships, but incorporates reasoning about the ontology. We illustrate the paper by the Mondial case study3 . The following examples give a rough idea of the difference between a plain ER model and the modeling in an ontology: Example 1 (ER Model) An ER model states that countries have functional attributes name, code, area, population, are in a one-to-one relationship capital and in a one-to-many relationship hasCity with one or more cities, and in an n : m-relationship neighbor with countries (the relationship has a functional attribute length), and an n : m-relationship isMember with organizations. Example 2 (Ontology) The concept hierarchy in an ontology is usually much more detailed since also abstract classes are used: Most Things (except such things as borders, reified things, etc.) have a functional property name. There are Areas that have functional properties area and population, and that are in n : m-relationship borders with other areas. There are AdministrativeAreas that are areas, and have a (at most one) capital. Countries are both Things and AdministrativeAreas, they also have a code, are in a one-to-many relationship hasCity with one or more cities. The neighbor relationship is a subproperty of the borders relationship, with the range Country. The borders relationship between countries is reified into Border, which is a Line. Lines have a functional length property (that is then also inherited e.g. to rivers). Usage of Annotation Properties. In OWL-DL, classes and properties are not allowed to have “normal” properties. Information about abstract/non-abstract classes and about reification issues is represented by owl:AnnotationProperties in the er: namespace: – c er:isa er:Class/er:Concrete/er:Abstract/er:Interface applies to all named classes of the application domain, and states whether a concept is intended to have instances (like Country, Province), is a generalization of concepts (like Admin- istrativeArea as a superclass of related concepts), or an abstraction like Area or Line (similar to an interface in Java) that adds a set of certain properties or constraints to concepts. – c er:isa er:ReifiedRelationship/er:SymmetricReifiedRelationship and c er:reifies p states whether a concept is a reification of a property. Annotation Properties will also be used during the ontology inspection for main- taining the correspondences between application classes and ad-hoc classes for testing containment. The mapping from an ER model to the relational model is rather standard (the basic already being defined in the original paper [1], and by now being taught in every database lecture). Given an OWL ontology (on the class/property level, not containing the instances), one can apply an analogous algorithm to the ontology. The outcome is the schema itself, plus the mapping information that is used to insert the information of triples into the appropriate tables, tuples, and columns, and for defining a SPARQL-to-SQL mapping for querying. 3 http://www.dbis.informatik.uni-goettingen.de/Mondial/#RDF 2 Structure of the Paper. The paper is structured as follows: Section 2 shortly reviews the main mapping rules for obtaining a relational schema from a con- ceptual schema. Section 3 describes the algorithm for developing the relational schema from an ontology. Section 4 deals with concretely extracting the appro- priate knowledge from the OWL-DL ontology. Section 5 gives a comparison with related work, and Section 6 concludes the paper. 2 Standard Mapping to a Relational Schema The mapping from an OWL ontology to a relational schema follows the same standard rules as from an ER diagram (cf. e.g. [2, Ch. 7]). The presentation is kept straightforward and informal, omitting some details. This is sufficient to show in Section 4 that rather simple ontology inspection capabilities, e.g., whether a property p is functional on a class c whose intersection with the domain d of p is nonempty, are required that are nevertheless cumbersome tasks given the current languages and tools. Example 3 Consider the following fragment from Mondial: every country has one or more cities, one of which is its capital. Every city is located in exactly one country, but not every city is a capital. The inverse of hasCity is named inCountry. name hasCity code < 1, ∗ > < 1, 1 > area Country City name < 1, 1 > < 0, 1 > population capital population Entity types: Entity types (= non-abstract classes) are mapped to tables where the set of attributes consists of all functional attributes. The key attributes are the same as for the ER model (for weak entity types, see textbooks). Since in RDF, for every resource, one of its URIs can be chosen as key (maintaining a same-as table if necessary), there are no weak entity types. For the above ex- ample, Country(uri,name,code,population,area) and City(uri,name,population) are such basic table schemas. Each multivalued attribute of an entity type is stored in a separate table whose attributes are the keys of the entity relation, and additionally, the at- tribute name. Relationship types: The ER model allows arbitrary n-ary relationships. In OWL ontologies, relationships with arity > 2 are always represented by reified classes; thus, the discussion can be confined to binary relations. There, 1 : n- (including 1:1), and n : m relationships have to be distinguished: 1 : n relationships can be included within the entity table of the n side. E.g., for the capital relationship, the country table is extended to Country(uri,name,code,population,area,capital) while for the hasCity 1 : n-relationship, the inverse inCountry extends the city 3 table to City(uri,name,population,inCountry,capital-). Note that the 1:1 relation- ship capital/capital- is at first represented in both directions; one direction can be removed. n : m relationships are mapped to separate tables whose attributes are the keys of the respective entity tables, and the attribute names are chosen according to the entity types (or the roles, in case of recursive relationships) e.g., locatedAt(city,water). Attributed n : m Relationship types – Reification: Attributes of relationships are added in the same way; but in OWL ontologies, relationships with attributes have also to be modeled by reified classes. Example 4 Consider the ER diagram of the isMember relationship between countries and organizations, e.g., Croatia is a candidate member of the EU: type name code Country < 1, ∗ > isM ember < 1, ∗ > Organization name Here, the OWL ontology models the relationship already as a reified class: :Membership rdfs:subClassOf :ReifiedThing; er:reifies :isMember. :ofCountry a owl:FunctionalProperty; rdfs:domain :Membership; owl:inverseOf :isInMembership; rdfs:range :Country. :inOrganization a owl:FunctionalProperty; rdfs:domain :Membership; owl:inverseOf :hasMembership; rdfs:range :Organization. :isMember rdfs:domain :Country; rdfs:range :Organization; owl:inverseOf :hasMember. Note the use of er:reifies, which is an AnnotationProperty. The resulting table schema for the ER diagram is isMember(country,organization, type), while from the ontology, the names are slightly different: Membership(ofCountry,inOrganization,type). Summarizing, all functional properties of entities (including reified ones) are stored in the entity tables, and all multivalued properties are stored in binary tables. 3 The Algorithm The algorithm conceptually follows the procedure when transforming an ER model to the relational model. The mapping information is stored in a single metadata table that represents all relevant knowledge about the correspondence between classes and their properties, and table names and attributes: The Mapping Dictionary is used to look up where to store an RDF triple (s, p, o), and how to retrieve properties of a resource s (which is required when translating SPARQL queries to SQL). It is a table of the form M D ⊆ (Classes × Properties) × (Tables × Columns × {+, –}) 4 with the semantics that ((c, p), (t, a, +)) denotes that property p of instances of class c is stored in table t in attribute (=column) a. ((c, p), (t, a, –)) denotes that the inverse of property p of instances of class c can be found in table t in attribute a. In the following, p is usually used for functional properties and for multivalued literal properties, and r for n : m properties. p– and r– denote the reverse direction. The mapping algorithm consists of the following steps: A1: Functional Properties For every non-abstract class c, the primary table schema t c contains a uri column, and columns for all functional proper- ties p. Put ((c, p), (t c, p, +)) into the Mapping Dictionary; for object-valued properties with range d, put also ((d, p– ), (t c, p, –)) into the MD. A2: Correction for 1:1 Properties For each object-valued 1:1-property (i.e., which has been inserted in both directions) p between non-abstract classes c and d (c = d for recursive relationships is possible), one direction is deleted: if there is a < 0, 1 > cardinality (i.e. the property is partial in one direction) on one side and a < 1, 1 > cardinality on the other, delete the direction from the < 0, 1 > side (and delete the MD entries referring to it). Otherwise, arbitrarily delete one of them (see Example 5 below). (Note that usually there are 1 : 1 properties that result from the reification of attributed 1 : n properties. These are total from the reified side and partial or total from the entity type side – delete the entity side.) A3: n : m Relationships For each n : m property r (do not consider r– sepa- rately, since it is covered by the mapping of r): – add a new table t r(dom, rge), – for each non-abstract class c whose intersection with the domain of r is not empty, put ((c, r), (t r, rge, +)) into the Mapping Dictionary. – for each non-abstract class d whose intersection with the range of r is not empty, put ((d, r– ), (t r, dom, +)) into the Mapping Dictionary. Note that instead of the generic column names (dom,rge), any other names can be chosen. A common choice is to use (c, d) where c is the least common superclass that covers the domain (which can be any DL class expression) of r, and d is the least common superclass that covers the range (which can also be any DL class expression) of r. If domain=range, then a common naming is (c1 , c2 ) or (c, r) (note that the column names are actually not relevant, because insertions and queries are only made on the RDF level and mapped to the database via the Mapping Dictionary). A4: Non-Functional Literal-Valued Properties Non-functional literal-valued properties are similar to n : m properties, with the only difference that there is no inverse navigation: For each non-functional literal-valued property r: – add a new table t r(dom, r), – for each non-abstract class c whose intersection with the domain of r is not empty, put ((c, r), (t r, r, +)) into the Mapping Dictionary. The above steps are complete for representing the conceptual model. 5 Theorem 1 The algorithm is complete and minimal, i.e. every property is fi- nally represented once in the tables, covering both directions in case of object- valued relationships. The Mapping Dictionary is also complete, including the inverses. Proof Sketch. – functional literal-valued properties: Step (A1) handles them. They have no inverse direction. – 1 : 1 object-valued properties: Step (A1) handles them in both directions (i.e., in both involved class tables); and (A2) deletes one direction. – non-functional (i.e., multivalued) literal properties: Step (A4) handles them. They have no inverse direction. – 1 : n and n : 1 object-valued properties: one direction is functional. It is handled in Step (A1). – n : m properties r: Step (A3) creates an n : m table for r which represents also r– . Example 5 (Functional Property and Partial 1:1 Relationship) Consider again the fragment from Mondial given in Example 3. The OWL-DL ontology is as follows: code is a 1:1 literal-valued property; capital is also 1:1, where every country has exactly 1 capital, but not every city is a capital of a country. :code a owl:FunctionalProperty; a owl:InverseFunctionalProperty; rdfs:domain :Country; rdfs:range xsd:string; owl:cardinality 1. :name a owl:FunctionalProperty; a owl:InverseFunctionalProperty; rdfs:domain [owl:UnionOf (:Country :City . . . )]; rdfs:range xsd:string; owl:cardinality 1. :capital a owl:FunctionalProperty; a owl:InverseFunctionalProperty; rdfs:domain :Country; rdfs:range :City; owl:inverseOf :isCapitalOf; owl:cardinality 1. The entries for code in the Mapping Dictionary are as follows: – The entry ((Country,code)(t Country,code,+)) states that for looking up the pattern {:germany a :Country; :code ?C}, the SQL query SELECT code FROM t Country WHERE uri=’:germany’ has to be stated. – For looking up the triple pattern {?X a :Country; :code ’D’}, the SQL query SELECT uri FROM t Country WHERE code=’D’ has to be stated. – analogously for Country.name and City.name. The capital relationship between Countries and Cities is functional in both direc- tions; its inverse is named isCapitalOf. So Step (A1) generates the following: – capital is mapped to a column in the t Country table: t Country(uri,name,code, capital). The MD entry is ((Country,capital)(t Country,capital,+)) that states that for looking up the triple pattern {:germany a :Country; :capital ?X}, the SQL 6 query SELECT capital FROM t Country WHERE uri=’:germany’ has to be stated (yielding the uri binding ?X/:berlin). The inverse MD entry is ((City,isCapitalOf)(t Country,capital,-)), stating that “for looking up isCapitalOf of a city (i.e., “of which country is the city with uri x the capital?”, one can instead lookup for a tuple in the t Country table whose capital column has the value x. The SPARQL query {:berlin a :City; :is- CapitalOf ?X} is then mapped to the SQL query SELECT uri FROM t Country WHERE capital=’:berlin’ – capital- = isCapitalOf is a functional object-valued property of cities (contain- ing many null values) mapped to a column in the City table: t City(uri,name, isCapitalOf,. . . ) yielding the MD entry ((City,isCapitalOf)(t City,isCapitalOf,+)). The inverse MD entry is ((Country,capital)(t City,isCapitalOf,-)). As a result so far, the capital/capital- property would be stored redundantly. Then, Step (A2) removes one direction (namely, the partial one, stored in the City table). The above example was rather easy, since the properties were globally func- tional. In general, for each subclass of the domain, functionality has to be checked individually. 4 Ontology Inspection for Schema Generation To keep the implementation as declarative as possible, it consists of a sequence of SPARQL queries against the TBox ontology, extended with auxiliary definitions. For all non-abstract classes, table schemata as described above are derived where all properties can be stored. If a user intends to tune the mapping, it is easy to merge tables by modifying the Mapping Dictionary accordingly. 4.1 Support for TBox Analysis in SPARQL SPARQL [3] itself is intended to be a query language for RDF, i.e., for querying triple patterns. Some OWL notions are directly and unambiguously represented by triples, such as c a owl:Class. Some others are directly supported by special handling in the reasoners, e.g., c rdfs:subClassOf d and c owl:equivalentClass d. On the other hand, for instance, from :p a owl:ObjectProperty; rdfs:domain :D. :D owl:equivalentClass [ a owl:Restriction; owl:onProperty :p; owl:maxCardinality 1 ]. p is not contained in the answer to ?P a owl:FunctionalProperty, although this is actually implied by the knowledge base. In the following, even more complex queries are needed, e.g., whether a given property p is functional on some class c that has a non-empty intersection with the domain of p. The following query –if it would be allowed– yields the answers: ?C rdfs:subClassOf [ a owl:Restriction; owl:onProperty :p; owl:maxCardinality 1 ]. 7 Such functionality is covered by the SPARQL OWL 2 Direct Semantics En- tailment Regime [4], building upon combining SPARQL with a DL reasoner. Concerning available implementations, a set of atomic built-in notions can be queried by SPARQL-DL [5, 6], but this is not sufficient for the TBox analysis required in the following. Reasoning for the SPARQL OWL 2 Direct Semantics Entailment Regime has been presented in [7, 8]. As long as there is no actual implementation available for using SPARQL, instead of a simple declarative query, one has 1. to define dummy classes fcttest c p for each relevant class/property combi- nation, 2. add them to the ontology, 3. and answer the query {c rdfs:subClassOf fcttest c p}. 4.2 Transformation Steps In the following, some of the ontology inspection steps are exemplarily described. Again, AnnotationProperties are needed to correlate test classes with application classes and properties. All properties in the aux: namespace are declared to be AnnotationProperties. 4.2.1 Auxiliary: Create Names for Unnamed Inverses Since in some cases, the inverses are needed as column names in the resulting tables, for all inverses that are not yet named, a synthetic name is created. Example 6 Consider that a river may have several estuaries (into some lakes it flows through, and finally into some sea/lake/river). This property hasEstuary is thus inverse-functional, i.e. every estuary belongs to one river. In this step, its inverse hasEstuary Inv is named and defined, e.g., :hasEstuary_Inv a owl:ObjectProperty; a aux:AddedInverseProperty; owl:inverseOf :hasEstuary. 4.2.2 Identify Functional Properties for each Class For each non-abstract class c, all properties p that are functional for instances of that class, and for which the intersection of c with the domain of p is non- empty are collected. Note that a functional property may be defined on an abstract class, and may be forbidden by additional restrictions for some concrete subclasses of its domain. Also, properties may be non-functional in general, but specified to be functional for certain subsets of the domain. Thus, simply checking the domain of p, and checking whether p is (globally) functional is not sufficient. Instead, test classes must be defined, added to the ontology, and appropriate queries must be stated: construct { [a owl:Restriction; owl:onProperty ?P; owl:maxCardinality 1] 8 aux:isa aux:Card1Test; aux:onDomain ?C; aux:onProperty ?P . [a owl:Restriction; owl:onProperty ?P; owl:allValuesFrom owl:Nothing ] aux:isa aux:NonEmptyTest; aux:onDomain ?C; aux:onProperty ?P. } where { ?C er:isa ?ERC . ?ERC rdfs:subClassOf er:Concrete . ?P a rdf:Property; rdfs:domain ?D; rdfs:range ?R. FILTER (?P != owl:bottomObjectProperty && ?P != owl:bottomDataProperty) # intersection may be non-empty -- (C disjoint D) not provable NOT EXISTS { ?C owl:disjointWith ?D } The query constructs the test class definitions for all relevant class/property- pairs. Example 7 Geographical things have a name; only estuaries are excluded from this (Estuary ⊑ ∀name.⊥). The property inCountry is n : m, but each admin- istrative area, where cities are a subset of, is located in exactly one country: (AdmArea ⊑ ∃1inCountry.⊤). The following are the relevant test classes – note the usage of Annotation- Properties from the aux namespace: [] aux:isa aux:NonEmptyTest; aux:onDomain :Estuary; aux:onProperty :name; a owl:Restriction ; owl:onProperty :name; owl:allValuesFrom owl:Nothing . [] aux:isa aux:Card1Test; aux:onDomain :City; aux:onProperty :inCountry; a owl:Restriction; owl:onProperty :inCountry; owl:maxCardinality 1 . The evaluation uses the annotations of the test class definitions, namely by checking whether c is a subclass of the cardinality≤1 test class, and whether c is not a subclass of the (c, p)-Non-Empty-Test class. construct { ?C aux:hasFunctProp ?P } where { ?C1T aux:isa aux:Card1Test; aux:onDomain ?C; aux:onProperty ?P . ?NET aux:isa aux:NonEmptyTest; aux:onDomain ?C ; aux:onProperty ?P . ?C rdfs:subClassOf ?C1T. NOT EXISTS { ?C rdfs:subClassOf ?NET } } Note that better efficiency can be gained when properties that are known to be globally functional (by querying for the explicit triple ?P a owl:FunctionalProperty) bypass the cardinality≤ 1 check. 4.2.3 Further Steps Further steps are not described in detail here: – for 1:1 properties remove one direction from the list (if one direction is total, choose this one), and create the Mapping Dictionary entries and the tables for the entity types, 9 – Note that reified relationships are already covered with this, since they are in n : 1 relationship with the contributing entity types, cf. Example 4. – for non-functional attributes and the remaining n : m properties, identify the column names, create the Mapping Dictionary entries and the tables, – handle symmetric relationships (e.g., mergesWith(sea1,sea2)) and create a view for the symmetric hull. As a further refinement, it is possible to distinguish between different range sub- classes to isolate functional subproperties. For instance, geographical things are usually located in several administrative areas (e.g., some provinces, some coun- tries), but cities are located in exactly one province of exactly one country – thus, for cities, instead of storing this information in an n : m table, two functional properties locatedIn Country and locatedIn Province can be added to the city ta- ble which makes query evaluation more efficient (note again that the column names are actually not relevant, because insertions and queries are only made on the RDF level and mapped to the database via the Mapping Dictionary). The description of the whole process can be found in [9]. 5 Related Work Several approaches discuss storage strategies for RDF data in relational databases. The efficiency of schema-aware vs. schema-oblivious relational storage represen- tations for RDF wrt. query evaluation has been investigated in [10], with the result that schema-aware representations yield a superior query performance; additionally, different storage representations of subsumption relationships (e.g., implicit vs. explicit) have been considered. This idea has been followed in the property tables approach [11] that results in a similar storage layout to the one we have chosen: triples are stored wrt. to a specific subject in the same table (the functional property table) which is comparable to our class tables, multi- valued properties are stored analogously to our layout for n : m properties. They additionally use a triple table for storing the data, which in our approach is not required. The mapping of the RDF data to the relational model is given explicitly and regardless of an available ontology, whereas in our case we au- tomatically derive the storage layout through an analysis of the ontology. The Sesame store [12] supports a dynamic database schema for PostgreSQL4 where new tables are added based on an analysis of the RDFS schema of an RDF graph. But they do not support a more advanced analysis of the relationships as sup- ported by our ontology analysis. A different approach was taken in [13], where the storage scheme is organized by a vertical partitioning on properties, i.e. each table is named after a property and contains exactly two columns, one for the subject and one for the object. In combination with a column-oriented relational DB, typical basic graph pattern queries can be answered by (sort-)merge joins. The downside of this storage organisation is that patterns where the property position contains a variable require a UNION over all tables. 4 http://www.postgresql.org 10 Commercial relational database systems also provide support for storing RDF graphs, e.g., Oracle stores the RDF data in a triples table-style representation where common join combinations can be cached as so-called subject-property matrix materialized join views, and queries on RDF graphs can be intermixed with regular SQL tables via a custom RDF MATCH SQL table function [14]. IBM also provides RDF support on top of its DB2 database system5 , where data is stored clustered on common subjects and also in the inverse direction clustered on objects, where the storage layout is optimized based on an analysis of in- stance data. In our approach the storage layout is determined at design time via ontology inspection, and no further optimization based on instance data is required. The SP 2 Bench benchmark experiment [15] has observed that a fully rela- tional DB schema outperforms generic RDF data storage strategies by a factor of typically at least one order of magnitude already for small document sizes. Our approach results in a fully relational DB schema storage schema as known from common ER transformations and as such makes optimal use of the avail- able schema information in an automatic fashion while retaining the appearance of an RDF store to the outside, i.e. regular RDF triples can be inserted. Also, the mapping dictionary gives us the full control of how we store each RDF triple physically with the opportunity to choose different storage layouts, if desired. Another related aspect is the investigation of SPARQL views over existing relational data. This direction is orthogonal to our approach and can be con- sidered as the inverse direction, i.e. how to use SPARQL queries to access the stored RDF triples. An approach based on a fixed set of mappings is the D2R server [16]. A recent project, called Quest [17], generates optimised SQL queries based on query containment checks, e.g. to eliminate redundant joins. For this, Quest relies on a mapping language that relates the notions of the domain ontol- ogy with the relational database. These mappings have to be defined manually by a skilled user. In future work, we want to investigate an integration of the Quest frontend with our storage layout, especially with a focus on the automatic generation of these mapping rules by an investigation of available meta data in our mapping dictionary. For a more complete survey of relational DB to RDF mappings the interested reader is referred to [18]. The DLR description logic [19, 20] uses general n-ary relations for expressing conceptual models such as the ER model and UML class diagrams. In contrast, in our approach, we derive a relational storage layout from a given OWL-DL ontology that has the same properties as the relational model derived from an ER diagram. 6 Conclusion We have shown a generic and declarative approach to obtain an application- specific relational schema from an OWL-DL ontology. The process is specified 5 http://researcher.watson.ibm.com/researcher/view_project.php?id=4416 11 completely declaratively by SPARQL queries, using AnnotationProperties for managing correspondences between classes, properties and auxiliary classes for ontology inspection. It cannot be executed inside SPARQL, but requires a se- quential external execution to create class definitions by SPARQL queries, and to feed them back into the reasoner before evaluating subsequent queries. References 1. Chen, P.: The Entity-Relationship Model — Towards a Unified View of Data. ACM TODS 1(1) (1976) 9–36 2. Elmasri, R., Navathe, S.B.: Fundamentals of Database Systems, 4th Edition. Addison-Wesley-Longman (2004) 3. W3C: SPARQL 1.1 Query Language. http://www.w3.org/TR/sparql11-query/ (2012) 4. W3C: SPARQL 1.1 Entailment Regimes. http://www.w3.org/TR/ sparql11-entailment/ (2013) 5. Sirin, E., Parsia, B.: SPARQL-DL: SPARQL Query for OWL-DL. OWLED (2007) 6. Clark&Parsia: Pellet: OWL 2 Reasoner for Java. http://clarkparsia.com/ pellet/ 7. Kollia, I., Glimm, B., Horrocks, I.: SPARQL Query Answering over OWL Ontolo- gies. ESWC (2011) 382–396 8. Information Systems Group, University of Oxford: Hermit OWL Reasoner. http: //www.hermit-reasoner.com/ 9. Hornung, T., May, W.: Efficient, Schema-Aware Storage of RDF Graphs. Technical report (2013) http://www.dbis.informatik.uni-goettingen.de/RDF2Rel/. 10. Theoharis, Y., Christophides, V., Karvounarakis, G.: Benchmarking Database Representations of RDF/S Stores. ISWC. Springer LNCS 3729 (2005) 685–701 11. Wilkinson, K.: Jena Property Table Implementation. Scalable Semantic Web Knowledge Base Systems. (2006) 12. Broekstra, J., Kampman, A., van Harmelen, F.: Sesame: A Generic Architecture for Storing and Querying RDF and RDF Schema. ISWC, Springer LNCS 2342 (2002) 54–68 13. Abadi, D.J., Marcus, A., Madden, S., Hollenbach, K.J.: Scalable Semantic Web Data Management Using Vertical Partitioning. VLDB. (2007) 411–422 14. Chong, E.I., Das, S., Eadon, G., Srinivasan, J.: An Efficient SQL-based RDF Querying Scheme. VLDB. (2005) 1216–1227 15. Schmidt, M., Hornung, T., Küchlin, N., Lausen, G., Pinkel, C.: An Experimental Comparison of RDF Data Management Approaches in a SPARQL Benchmark Scenario. ISWC. Springer LNCS 5318 (2008) 82–97 16. Bizer, C.: D2R MAP — A Database to RDF Mapping Language. WWW (2003) 17. Rodriguez-Muro, M., Hardi, J., Calvanese, D.: Quest: Efficient SPARQL-to-SQL for RDF and OWL. ISWC Posters & Demos. Vol. 914 of CEUR Workshop Pro- ceedings. CEUR-WS.org (2012) 18. Sahoo, S.S., Halb, W., Idehen, S.H.K., Jr, T.T., Auer, S., Sequeda, J., Ezzat, A.: A Survey of Current Approaches for Mapping of Relational Databases to RDF. Technical report, W3C RDB2RDF Incubator Group (January 2009) 19. Calvanese, D., Lenzerini, M., Nardi, D.: Description Logics for Conceptual Data Modeling. Logics for Databases and Information Systems, Kluwer (1998) 229–263 20. Cali, A., Calvanese, D., Giacomo, G.D., Lenzerini, M.: A Formal Framework for Reasoning in UML Class Diagrams. ISMIS. Springer LNAI 2366 (2002) 503–513 12