Mapping to RDF Graphs

Editors

Peter F. Patel-Schneider, Nuance Communications

Boris Motik, University of Oxford

Contributors (alphabetical order)

Bernardo Cuenca Grau, University of Oxford

Ian Horrocks, University of Oxford

Bijan Parsia, University of Manchester

Alan Ruttenberg, Science Commons (Creative Commons)

Michael Schneider, FZI Research Center for Information Technology

[Show Short TOC]

[Show Full TOC]

1 Introduction and Preliminaries

This document defines two mappings between the structural specification of OWL 2 [OWL 2 Specification] and RDF graphs [RDF Concepts]. The mapping presented in Section 2 can be used to transform any OWL 2 ontology O into an RDF graph T(O). The mapping presented in Section 3 can be used to transform an RDF graph G satisfying certain restrictions into an OWL 2 DL ontology O_G. These transformations do not incur any change in the formal meaning of the ontology. More precisely, for any OWL 2 DL ontology O, let G = T(O) be the RDF graph obtained by transforming O as specified in Section 2, and let O_G be the OWL 2 DL ontology obtained by applying the reverse transformation from Section 3 to G; then, O and O_G are logically equivalent — that is, they have exactly the same set of models.

The mappings presented in this document are backwards-compatible with that of OWL 1 DL: every OWL 1 DL ontology encoded as an RDF graph can be mapped into a valid OWL 2 DL ontology using the mapping from Section 3 such that the resulting OWL 2 DL ontology has exactly the same set of models as the original OWL 1 DL ontology.

The syntax for triples used in this document is the one used in the RDF Semantics [RDF Semantics]. Full IRIs are abbreviated using the prefixes from the OWL 2 Specification [OWL 2 Specification]. OWL 2 ontologies mentioned in this document should be understood as instances of the structural specification of OWL 2 [OWL 2 Specification]; when required, these are written in this document using the functional-style syntax.

The following notation is used throughout this document for referring to parts of RDF graphs:

• *:x denotes an IRI;
• _:x denotes a blank node;
• x denotes a blank node or an IRI;
• lt denotes a literal; and
• xlt denotes a blank node, an IRI, or a literal.

The italicized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used to specify normative features of OWL 2 documents and tools, and are interpreted as specified in RFC 2119 [RFC 2119].

2 Mapping from the Structural Specification to RDF Graphs

This section defines a mapping of an OWL 2 ontology O into an RDF graph T(O). The mapping is presented in three parts. Section 2.1 shows how to translate axioms that do not contain annotations, Section 2.2 shows how to translate annotations, and Section 2.3 shows how to translate axioms containing annotations.

2.1 Translation of Axioms without Annotations

Table 1 presents the operator T that maps an OWL 2 ontology O into an RDF graph T(O), provided that no axiom in O is annotated. The mapping is defined recursively; that is, the mapping of a construct often depends on the mappings of its subconstructs, but in a slightly unusual way: if the mapping of a construct refers to the mapping of a subconstruct, then the triples generated by the recursive invocation of the mapping on the subconstruct are added to the graph under construction, and the main node of the mapping of the subconstruct is used in place of the recursive invocation itself.

The definition of the operator T uses the operator TANN in order to translate annotations. The operator TANN is defined in Section 2.2. It takes an annotation and an IRI or a blank node and produces the triples that attach the annotation to the supplied object.

In the mapping, each generated blank node (i.e., each blank node that does not correspond to an anonymous individual) is fresh in each application of a mapping rule. Furthermore, possible conditions on the mapping rules are enclosed in curly braces '{ }'. Finally, the following conventions are used in this section to denote different parts of OWL 2 ontologies:

• OP denotes an object property;
• OPE denotes an object property expression;
• DP denotes a data property;
• DPE denotes a data property expression;
• AP denotes an annotation property;
• C denotes a class;
• CE denotes a class expression;
• DT denotes a datatype;
• DR denotes a data range;
• U denotes an IRI;
• F denotes a constraining facet;
• a denotes an individual (named or anonymous);
• *:a denotes a named individual;
• lt denotes a literal;
• as denotes an annotation source; and
• av denotes an annotation value.

In this section, T(SEQ y₁ ... y_n) denotes the translation of a sequence of objects from the structural specification into an RDF list, as shown in Table 1.

2.2 Translation of Annotations

The operator TANN, which translates annotations and attaches them to an IRI or a blank node, is defined in Table 2.

2.3 Translation of Axioms with Annotations

If an axiom ax contains embedded annotations annotation₁ ... annotation_m, its serialization into RDF depends on the type of the axiom. Let ax' be the axiom that is obtained from ax by removing all axiom annotations.

2.3.1 Axioms that Generate a Main Triple

If the row of Table 1 corresponding to the type of ax' contains a single main triple s p xlt ., then the axiom ax is translated into the following triples:

This is the case if ax' is of type SubClassOf, DisjointClasses with two classes, SubObjectPropertyOf without a property chain as the subproperty expression, SubDataPropertyOf, ObjectPropertyDomain, DataPropertyDomain, ObjectPropertyRange, DataPropertyRange, InverseObjectProperties, FunctionalObjectProperty, FunctionalDataProperty, InverseFunctionalObjectProperty, ReflexiveObjectProperty, IrreflexiveObjectProperty, SymmetricObjectProperty, AsymmetricObjectProperty, TransitiveObjectProperty, DisjointObjectProperties with two properties, DisjointDataProperties with two properties, ClassAssertion, ObjectPropertyAssertion, DataPropertyAssertion, Declaration, DifferentIndividuals with two individuals, or AnnotationAssertion.

For ax' of type DisjointUnion, SubObjectPropertyOf with a subproperty chain, or HasKey, the first triple from the corresponding row of Table 1 is the main triple and it is subjected to the transformation described above; the other triples from the corresponding row of Table 1 — called side triples — are output without any change.

2.3.2 Axioms that are Translated to Multiple Triples

If the axiom ax' is of type EquivalentClasses, EquivalentObjectProperties, EquivalentDataProperties, or SameIndividual, its translation into RDF can be broken up into several RDF triples (because RDF can only represent binary relations). In this case, each of the RDF triples obtained by the translation of ax' is transformed as described in previous section, and the annotations are repeated for each of the triples obtained in the translation.

2.3.3 Axioms Represented by Blank Nodes

If the axiom ax' is of type NegativeObjectPropertyAssertion, NegativeDataPropertyAssertion, DisjointClasses with more than two classes, DisjointObjectProperties with more than two properties, DisjointDataProperties with more than two properties, or DifferentIndividuals with more than two individuals, then its translation already requires introducing a blank node _:x. In such cases, ax is translated by first translating ax' into _:x as shown in Table 1, and then attaching the annotations of ax to _:x.

3 Mapping from RDF Graphs to the Structural Specification

This section specifies the results of steps CP 2.2 and CP 3.3 of the canonical parsing process from Section 3.6 of the OWL 2 Specification [OWL 2 Specification] on an ontology document D that can be parsed into an RDF graph G. An OWL 2 tool MAY implement these steps in any way it chooses; however, the results MUST be structurally equivalent to the ones defined in the following sections. These steps do not depend on the RDF syntax used to encode the RDF graph in D; therefore, the ontology document D is identified in this section with the corresponding RDF graph G.

An RDF syntax ontology document is any document accessible from some given IRI that can be parsed into an RDF graph, and that then be transformed into an OWL 2 ontology by the canonical parsing process instantiated as specified in this section.

The following sections contain rules in which triple patterns are matched to G. Note that if a triple pattern contains a variable number of triples, the maximal possible subset of G MUST be matched.

The following notation is used in the patterns:

• The notation NN_INT(n) can be matched to any literal whose value n is a nonnegative integer.
• Possible conditions on the pattern are enclosed in curly braces '{ }'.
• Some patterns use optional parts, which are enclosed in square brackets '[ ]'.
• The abbreviation T(SEQ y₁ ... y_n) denotes the pattern corresponding to RDF lists, as shown in Table 3. When a list pattern is matched to G, all list variables _:x_i and _:x_j with i ≠ j MUST be matched to different nodes; furthermore, it MUST NOT be possible to match the list pattern to two maximal subsets of G such that some list variable in the first pattern instance is matched to the same node as some (possibly different) variable in the second pattern instance. This is necessary in order to detect malformed lists such as lists with internal cycles, lists that share tails, and lists that cross.

3.1 Extracting Declarations and the IRIs of the Directly Imported Ontology Documents

This section specifies the result of step CP 2.2 of the canonical parsing process on an RDF graph G.

3.1.1 Resolving Included RDF Graphs

For backwards compatibility with OWL 1 DL, if G contains an owl:imports triple pointing to an RDF document encoding an RDF graph G' where G' does not have an ontology header, this owl:imports triple is interpreted as an include rather than an import — that is, the triples of G' are included into G and are not parsed into a separate ontology. To achieve this, the following transformation is applied to G as long as the following rule is applicable to G.

3.1.2 Parsing of the Ontology Header and Declarations

Next, the ontology header is extracted from G by matching patterns from Table 4 to G. It MUST be possible to match exactly one such pattern to G in exactly one way. The matched triples are removed from G. The set Imp(G) of the IRIs of ontology documents that are directly imported into G contains exactly all *:z₁, ..., *:z_k that are matched in the pattern.

Next, for backwards compatibility with OWL 1 DL, certain redundant triples are removed from G. In particular, if the triple pattern from the left-hand side of Table 5 is matched in G, then the triples on the right-hand side of Table 5 are removed from G.

Next, for backwards compatibility with OWL 1 DL, G is modified such that declarations can be properly extracted in the next step. When a triple pattern from the first column of Table 6 is matched in G, the matching triples are replaced in G with the triples from the second column. This matching phase stops when matching a pattern and replacing it as specified does not change G. Note that G is a set and thus cannot contain duplicate triples, so this last condition prevents infinite matches.

Next, the set of declarations Decl(G) is extracted from G according to Table 7. The matched triples are not removed from G — the triples from Table 7 can contain annotations so, in order to correctly parse the annotations, they will be matched again in the step described in Section 3.2.5.

Finally, the set RIND of blank nodes used in reification is identified. This is done by initially setting RIND = ∅ and then applying the patterns shown in Table 8. The matched triples are not deleted from G.

3.2 Populating an Ontology

This section specifies the result of step CP 3.3 of the canonical parsing process on an RDF graph G, the corresponding instance O_G of the Ontology class, and the set AllDecl(G) of all declarations for G computed as specified in step CP 3.1 of the canonical parsing process.

3.2.1 Analyzing Declarations

The following functions map an IRI or a blank node x occurring in G into an object of the structural specification. In particular,

• CE(x) maps x into a class expression,
• DR(x) maps x into a data range,
• OPE(x) maps x into an object property expression,
• DPE(x) maps x into a data property expression, and
• AP(x) maps x into an annotation property.

Initially, these functions are undefined for all IRIs and blank nodes occurring in G; this is written as CE(x) = ε, DR(x) = ε, OPE(x) = ε, DPE(x) = ε, and AP(x) = ε. The functions are updated as parsing progresses. All of the following conditions MUST be satisfied at any given point in time during parsing.

• For each x, at most one of OPE(x), DPE(x), and AP(x) is defined.
• For each x, at most one of CE(x) and DR(x) is defined.

Furthermore, the value of any of these functions for any x MUST NOT be redefined during parsing (i.e., if a function is not undefined for x, no attempt should be made to change the function's value for x).

Functions CE, DR, OPE, DPE, and AP are initialized as shown in Table 9.

3.2.2 Parsing of Annotations

The annotations in G are parsed next. The function ANN assigns a set of annotations ANN(x) to each IRI or blank node x. This function is initialized by setting ANN(x) = ∅ for each each IRI or blank node x. Next, the triple patterns from Table 10 are matched in G and, for each matched pattern, ANN(x) is extended with an annotation from the right column. Each time one of these triple patterns is matched, the matched triples are removed from G. This process is repeated until no further matches are possible.

3.2.3 Parsing of Ontology Annotations

Let x be the node that was matched in G to *:x or _:x according to the patterns from Table 4; then, ANN(x) determines the set of ontology annotations of O_G.

3.2.4 Parsing of Expressions

Next, functions OPE, DR, and CE are extended as shown in Tables 11, 12, and 13, as well as in Tables 14 and 15. The patterns in the latter two tables are not generated by the mapping from Section 2, but they can be present in RDF graphs that encode OWL 1 DL ontologies. Each time a pattern is matched, the matched triples are removed from G. Pattern matching is repeated until no triple pattern can be matched to G.

3.2.5 Parsing of Axioms

Next, O_G is populated with axioms. For clarity, the axiom patterns are split into two tables.

• Table 16 presents the patterns for axioms without annotations.
• Annotated axioms are parsed as follows:
  • In case of the patterns for owl:AllDisjointClasses, owl:AllDisjointProperties, owl:AllDifferent, and owl:NegativePropertyAssertion, axiom annotations are defined by ANN(_:x).
  • For all other axioms, axiom annotations are obtained by additionally matching patterns from Table 17 in G during axiom matching.

The axioms in G are parsed as follows:

• All annotated axioms are parsed first.
• Only when no pattern for annotated axioms can be matched in G, then the patterns for axioms without annotations are matched.

In either case, each time a triple pattern is matched, the matched triples are removed from G.

Next, for each blank node or IRI x such that x ∉ RIND, and for each annotation Annotation( annotation₁ ... annotation_n AP y ) ∈ ANN(x) with n possibly being equal to zero, the following annotation assertion is added to O_G:

Finally, the patterns from Table 18 are matched in G and the resulting axioms are added to O_G. These patterns are not generated by the mapping from Section 2, but they can be present in RDF graphs that encode OWL 1 DL ontologies. (Note that the patterns from the table do not contain triples of the form *:x rdf:type owl:Class because such triples are removed while parsing the entity declarations, as specified in Section 3.1.2.) Each time a triple pattern is matched, the matched triples are removed from G.

At the end of this process, the graph G MUST be empty.

5 Acknowledgments

The starting point for the development of OWL 2 was the OWL1.1 member submission, itself a result of user and developer feedback, and in particular of information gathered during the OWL Experiences and Directions (OWLED) Workshop series. The working group also considered postponed issues from the WebOnt Working Group.

This document has been produced by the OWL Working Group (see below), and its contents reflect extensive discussions within the Working Group as a whole. The editors extend special thanks to Markus Krötzsch (FZI), Alan Ruttenberg (Science Commons), Uli Sattler (University of Manchester), Michael Schneider (FZI) and Evren Sirin (Clark & Parsia) for their thorough reviews.

The regular attendees at meetings of the OWL Working Group at the time of publication of this document were: Jie Bao (RPI), Diego Calvanese (Free University of Bozen-Bolzano), Bernardo Cuenca Grau (Oxford University Computing Laboratory), Martin Dzbor (Open University), Achille Fokoue (IBM Corporation), Christine Golbreich (Université de Versailles St-Quentin and LIRMM), Sandro Hawke (W3C/MIT), Ivan Herman (W3C/ERCIM), Rinke Hoekstra (University of Amsterdam), Ian Horrocks (Oxford University Computing Laboratory), Elisa Kendall (Sandpiper Software), Markus Krötzsch (FZI), Carsten Lutz (Universität Bremen), Deborah L. McGuinness (RPI), Boris Motik (Oxford University Computing Laboratory), Jeff Pan (University of Aberdeen), Bijan Parsia (University of Manchester), Peter F. Patel-Schneider (Bell Labs Research, Alcatel-Lucent), Sebastian Rudolph (FZI), Alan Ruttenberg (Science Commons), Uli Sattler (University of Manchester), Michael Schneider (FZI), Mike Smith (Clark & Parsia), Evan Wallace (NIST), Zhe Wu (Oracle Corporation), and Antoine Zimmermann (DERI Galway). We would also like to thank past members of the working group: Jeremy Carroll, Jim Hendler, and Vipul Kashyap.

6 References

[OWL 2 Specification]

OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax. Boris Motik, Peter F. Patel-Schneider, and Bijan Parsia, eds., 2009.

[RDF Concepts]

Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne and Jeremy J. Carroll, eds. W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Latest version available as http://www.w3.org/TR/rdf-concepts/.

[RDF Semantics]

RDF Semantics. Patrick Hayes, ed., W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. Latest version available as http://www.w3.org/TR/rdf-mt/.

[RFC 2119]

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Network Working Group, S. Bradner. IETF, March 1997, http://www.ietf.org/rfc/rfc2119.txt