Mapping to RDF Graphs

Authors

Bernardo Cuenca Grau, Oxford University

Boris Motik, Oxford University

Peter F. Patel-Schneider, Bell Labs Research, Alcatel-Lucent

Contributors

Ian Horrocks, Oxford University

Bijan Parsia, The University of Manchester

1 Introduction and Preliminaries

This document provides mappings by means of which every OWL 2 ontology in the functional-style syntax [OWL 2 Specification] can be mapped into RDF triples and back without any change in the formal meaning of the ontology. More precisely, let O be any OWL 2 ontology in functional-style syntax, let RDF(O) be the set of RDF triples obtained by transforming O into RDF triples as specified in Section 2, and let O' be the OWL 2 ontology in functional-style syntax obtained by applying the reverse transformation from Section 3 to RDF(O); then, O and O' are logically equivalent — that is, they have exactly the same set of models.

The RDF syntax of OWL 2 is backwards-compatible with that of OWL DL: every OWL DL ontology in RDF syntax can be mapped into a valid OWL 2 ontology using the reverse-transformation from Section 3 such that the resulting OWL 2 ontology has exactly the same set of models as the original OWL DL ontology.

The syntax for triples used in this document is the one used in the RDF Semantics [RDF Semantics]. Full URIs are abbreviated using the namespaces from the OWL 2 Specification [OWL 2 Specification].

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

• *:x denotes a URI reference;
• _:x denotes a blank node;
• x denotes a blank node or a URI reference; and
• lt denotes a literal.

2 Mapping from Functional-Style Syntax to RDF Graphs

This section defines a mapping of an OWL 2 ontology O in functional-style syntax into a set of RDF triples RDF(O). The mapping is presented in two parts. Section 2.1 shows how to translate axioms that do not contain annotations, and Section 2.2 shows how to translate annotated axioms.

2.1 Translation of Axioms without Annotations

Table 1 presents the operator T that maps an OWL 2 ontology O in functional-style syntax into a set of RDF triples RDF(O), provided that no axiom in O is annotated. In the mapping of DatatypeRestriction, facet_i can be one of the facets listed in Section 7.3 of the OWL 2 Specification [OWL 2 Specification], and xsd:facet_i is a URI resource whose namespace is xsd: and whose fragment is the facet name. In the mapping, each generated blank node (i.e., all except for blank nodes corresponding to anonymous individuals) is fresh in each application of a mapping rule. Furthermore, the following conventions are used in this section to denote different syntactic 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;
• PE denotes an object or a data property expression;
• AP denotes an annotation property;
• C denotes a class;
• CE denotes a class expression;
• DT denotes a data type;
• DR denotes a data range;
• a denotes an individual (named or anonymous);
• *:a denotes a named individual;
• _:a denotes an anonymous individual;
• lt denotes a literal; and
• elt denotes an entity, an anonymous individual, or a literal.

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

2.2 Translation of Annotated Axioms

If an axiom ax contains embedded annotations Annotation( AP_i elt_i ), 1 ≤ i ≤ n, its serialization into RDF depends on the type of the axiom. In the following discussion, let ax' be the axiom that is equivalent to ax but that contains no annotations. Note that the Label and Comment annotations are just abbreviations, so they are serialized into RDF by expanding the abbreviation and then applying the serialization presented here.

2.2.1 Axioms that Generate a Single Triple or that Have a Main Triple

If ax' is translated into a single RDF triple s p o, then the axiom ax generates the following triples instead of triple s p o:

This is the case for the following axioms: SubClassOf, DisjointUnion, DisjointClasses with two classes, SubPropertyOf with a property chain as the subproperty expression, PropertyDomain, PropertyRange, InverseProperties, TransitiveProperty, FunctionalProperty, InverseFunctionalProperty, ReflexiveProperty, IrreflexiveProperty, SymmetricProperty, AsymmetricProperty, ClassAssertion, PropertyAssertion, Declaration, and DifferentIndividuals with two individuals.

Axioms SubPropertyOf with a subproperty chain and KeyFor are, without annotations, translated into several, and not a single triple. If such such axioms are annotated, then the main triple is subjected to the transformation described above. The other triples — called side triples — are output without any change.

2.2.2 Axioms that are Translated to Multiple Triples

If the axiom ax' is of type EquivalentClasses, EquivalentProperties, DisjointProperties, SameIndividual, or EntityAnnotation 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.2.3 Axioms Represented by Blank Nodes

If the axiom ax' is of type NegativePropertyAssertion, DisjointClasses with more than two classes, 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 2, and then attaching the annotations of ax to _:x.

2.2.4 Annotations on Annotations

An annotation always generates a single triple or a group of similar triples (for axioms that are translated to multiple triples) for the annotation (which are in addition to the triples used to represent the axiom being annotated for annotation axioms). An annotation on this annotation generates the following triples instead of each triple produced by the annotation s p o:

Deeper nesting is handled in the same way.

3 Mapping from RDF Graphs to Functional-Style Syntax

This section specifies canonical RDF parsing — a process that can be used to transform a set of RDF triples G into an OWL 2 ontology O in functional-style syntax, if possible. This process is specified as an instance of canonical parsing, defined in Section 5.9.3 of the OWL 2 Specification [OWL 2 Specification]. It is important to understand that canonical RDF parsing merely defines the result of the transformation. An OWL 2 implementation is free to implement whatever algorithm it chooses, as long as the result is structurally equivalent to the result of canonical RDF parsing.

Canonical RDF parsing maintains the following functions that can map an URI reference or a blank node x occurring in G into a fragment of the functional-style syntax. 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 URIs 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. If at any point in time the following conditions become invalidated, G is rejected as syntactically incorrect.

• For each x, at most one of OPE(x), DPE(x), and AP(x) can be defined.
• For each x, at most one of CE(x) and DR(x) can be defined.
• The rules from the following sections are not allowed to redefine the value of any of these functions for some x.

The following sections contain rules in which triple patterns are matched to G. The following notation is used to denote parts of the patterns that are matched to literals with integer value:

• POS_INT(n) is matched to any literal whose value is a positive integer;
• NN_INT(n) is matched to any literal whose value 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. If a pattern contains a variable number of triples, it must be matched to the maximal possible subset of G. The abbreviation T(SEQ y₁ ... y_n) denotes the pattern corresponding to RDF lists, as shown in Table 2.

3.1 Parsing Ontology Header and Declarations

First, the ontology header is extracted from G. In particular, if G does not contain a triple whose predicate is rdf:type and object is owl:Ontology, then the ontology header is Ontology( ... ). Otherwise, patterns from Table 3 are matched to G; if no such pattern can be matched in G, or if the pattern can be matched to G in more than one way, the graph G is rejected as invalid. The matched triples are removed from G.

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

Next, for backwards compatibility with OWL 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 5 is matched in G, the matching triples are replaced in G with the triples from the second column.

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

3.2 Parsing the Imported Ontologies

Next, for each ontology O' imported into O, the ontology header and declarations are determined. If the ontology O' is written in RDF then this is done as above. If the ontology O' is written in some other format then the ontology header and declarations are determined according to the rules appropriate to the ontology format.

3.3 Declaration Checking and Initialization

The set AllDecl(O) of all declarations is computed by taking the union of the set Decl(O), the sets Decl(O') for each ontology O' imported (directly or indirectly) into O, and the declarations for built-in entities from Table 2 of the OWL 2 Specification [OWL 2 Specification]. The declarations in AllDecl(O) are checked for typing constraints, as specified in Section 5.9.1 of the OWL 2 Specification [OWL 2 Specification]. If the constraints are not satisfied, the graph G is rejected as syntactically incorrect.

Next, the functions CE, DR, OPE, DPE, and AP are initialized as shown in Table 7.

The function OPEorDPE is defined as follows: OPEorDPE(x) = OPE(x) if OPE(x) ≠ ε; OPEorDPE(x) = DPE(x) if DPE(x) ≠ ε; and OPEorDPE(x) = ε otherwise.

3.4 Parsing of Annotations

Triples of the form x *:y *:z where *:y is an annotation property (that is, where AP(*:y) ≠ ε) are encountered in a number of patterns and they correspond to a set of annotations, denoted as ExpandAnnotations( x *:y *:z ), as described in Table 8. Thus, ExpandAnnotations( x *:y *:z ) contains the annotations that correspond to all possible interpretations of *:z as an entity.

To handle annotations on annotations any triple match for s p o that produces an annotation (either directly or via ExpandAnnotations), also allows a match of the four-triple pattern
_:x rdf:type owl:Annotation
_:x owl:subject s
_:x owl:predicate p
_:x owl:object o
and for each triple in G with _:x as the subject adds annotations to the each annotation generated as follows:

Any matched triples are removed.

3.5 Parsing of Axioms

Let x be the node that is matched to *:x or _:x while parsing the ontology header of O according to the patters from Table 2. The triples in G matching the patterns shown in Table 9 are converted to ontology annotations of O as shown in the table. The matched triples are removed from G.

Next, the functions OPE, DR, and CE are extended as shown in Tables 10, 11, and 12, as well as in Tables 13 and 14. 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 DL ontologies. Each time a pattern is matched, the matched triples are removed from G. Pattern matching is repeated as long until no triple pattern can be matched to G.

The ontology O is then populated with axioms. The patterns from Table 15 are matched in G, the resulting axioms are added to O, and the matched triples are removed from G.

For clarity, Table 15 ignores annotations on axioms. In case of the patterns for owl:AllDisjointClasses, owl:AllDisjointProperties, owl:AllDifferent, and owl:NegativePropertyAssertion, axiom annotations are obtained by additionally maximally matching patterns from Table 16 in G during axiom matching. For other axioms, axiom annotations are obtained by additionally matching patterns from Table 17 in G during axiom matching. All matched triples are then discarded from G.

Finally, the patterns from Table 18 are matched in G, the resulting axioms are added to O, and the matched triples are removed from G. These patterns are not generated by the mapping from Section 2, but they can be present in RDF graphs that encode OWL 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 deleted while parsing the entity declarations, as specified in Section 3.1).

At the end of this process, if G is not empty, then G is rejected as syntactically invalid.

4 References

[OWL 2 Specification]

OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax. Peter F. Patel-Schneider, Ian Horrocks, and Boris Motik, eds., 2006.

[OWL 2 Semantics]

OWL 2 Web Ontology Language: Model-Theoretic Semantics. Bernardo Cuenca Grau and Boris Motik, eds., 2006.

[RDF Semantics]

RDF Semantics. Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.