OWL 2 Web Ontology Language:
Mapping to RDF Graphs

W3C Editor's Draft 11 April22 September 2008

This version:

http://www.w3.org/2007/OWL/draft/ED-owl2-mapping-to-rdf-20080411/http://www.w3.org/2007/OWL/draft/ED-owl2-mapping-to-rdf-20080922/

Latest editor's draft:

http://www.w3.org/2007/OWL/draft/owl2-mapping-to-rdf/

Previous version:

http://www.w3.org/2007/OWL/draft/WD-owl11-mapping-to-rdf-20080108/http://www.w3.org/2007/OWL/draft/ED-owl2-mapping-to-rdf-20080411/ (color-coded diff)

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

---

Copyright © 2008 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Set of Documents

This document is being published as one of a set of 68 documents:

1. Structural Specification and Functional-Style Syntax
2. Model-Theoretic Semantics
3. RDF-Based Semantics
4. Mapping to RDF Graphs (this document)
5. XML Serialization
6. Profiles
7. Primer Summary of Changes Since the previous Working Draft (dated 8 January 2008), the only change is the name of the language, from "OWL 1.1" to "OWL 2". Since the group is publishing three new Working Drafts,Conformance and the name has changed, it decided to publish the complete set with consistent names.Test Cases
8. A Datatype for Internationalized Text

Please Comment By 11 May 2008ASAP

The OWL Working Group seeks public feedback on these Working Drafts. Please send your comments to public-owl-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted which may address your concerns.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

[Show Short TOC]

[Show Full TOC]

This document provides a mapping from the functional-style syntaxmappings by means of which every OWL 2 as givenontology in the functional-style syntax [OWL 2 Specification] to thecan be mapped into RDF exchange syntax for OWL 2triples and vice versa. Everyback without any change in the formal meaning of the ontology. More precisely, let O be any OWL 2 ontology canin functional-style syntax, let T(O) be serializedthe set of RDF triples obtained by transforming O into RDF triples as specified in RDF, so everySection 2, and let O' be the OWL 2 ontology in RDF is a valid OWL Full ontology.functional-style syntax obtained by applying the reverse transformation from Section 3 to T(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, this is,DL: every OWL DL ontology in RDF issyntax can be mapped into a valid OWL 2 ontology.ontology using the semanticsreverse-transformation from Section 3 such that the resulting OWL 2 is defined for ontologies inontology has exactly the functional-style syntax.same set of models as the original OWL 2 ontologies serialized in RDF/XML are interpreted by translating them into the functional-style syntax and applying the OWL 2 semantics [ OWL 2 Semantics ].DL ontology.

The syntax for triples used herein this document is the one used in the RDF Semantics document.[RDF Semantics]. Full URIs are abbreviated using namespaces as usual. Editor's Note:the actualnamespaces used infrom the OWL 2 Specification are subject to discussion and might change in future.[OWL 2 Specification].

The following notation is used throughout this document: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 named node; !xURI reference; and
• lt denotes a named node;literal.

The italicized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and T(SEQ y 1 ... y n ) denotesMAY specify certain aspects of the encodingnormative behavior of an RDF listOWL 2 tools, and are interpreted as shownspecified in Table 1. Table 1. Transformation of Sequences to Triples Sequence S Transformation T(S) Main Node of T(S) SEQ rdf:nil SEQ y 1 ... y n _:x rdf:type rdf:List _:x rdf:first T(y 1 ) _:x rdf:rest T(SEQ y 2 ... y n ) _:xRFC 2119 [RFC 2119].

Editor's Note: See Issue-2 (allDisjoint-RDF), Issue-68 (nonmonotonic mapping) and Issue-81 (reification, negative assertions). As explained in [ OWL 2 Specification ],This section defines a mapping of an OWL 2 ontology O in functional-style syntax is fully typed -- that is, from the syntax, one can immediately see what is the intendend usageinto a set of some symbol. OWL 1.0 syntaxRDF triples T(O). The mapping is not typed; rather, OWL 1.0 relies on explicit statementspresented in three parts. Section 2.1 shows how to translate axioms that determine the typedo not contain annotations, Section 2.2 shows how to translate annotations, and Section 2.3 shows how to translate axioms containing annotations.

The definition refers to a parse tree only forof the axioms from O , and not fromoperator T uses the axioms from some ontology that O imports. A symbol S in punnedoperator TANN in an ontology O if Type(S,O) contains more than one element. Based on that,order to translate annotations. The following two conditions are defined: OnlyOP(S)operator TANN is true if and only if owl:ObjectProperty ∈ Type(S,O) and owl:DatatypeProperty and owl:AnnotationProperty are notdefined in Type(S,O) ; OnlyDP(S) is true if and only if owl:DatatypeProperty ∈ Type(S,O)Section 2.2. It takes an annotation and owl:ObjectPropertyan URI reference or a blank node and owl:AnnotationProperty are notproduces the triples that attach the annotation to the supplied object.

In Type(S,O) ; OnlyAP(S)the mapping of DatatypeRestriction, facet_i is true if and only if owl:AnnotationProperty ∈ Type(S,O)one of the constraining facets listed in Section 4 of the OWL 2 Specification [OWL 2 Specification], and owl:ObjectPropertyxsd:facet_i is a URI resource whose namespace is xsd: and owl:DatatypeProperty arewhose fragment is the constraining facet name. In the mapping, each generated blank node (i.e., each blank node that does not correspond to an anonymous individual) is fresh in Type(S,O) .each application of a mapping rule. Furthermore, the following shortcutsconventions are used in the translationthis section to denote different syntactic parts of OWL 2 ontologies into RDF: RESTRICTION[op] expands to owl:Restriction if OnlyOP(op) = true , and to owl11:ObjectRestriction otherwise; RESTRICTION[dp] expands to owl:Restriction if OnlyDP(dp) = true , and to owl11:DataRestriction otherwise; SUBPROPERTYOF[op 1 ,...,op n ] expands to rdfs:subPropertyOf if OnlyOP(op i ) = true for each 1 ≤ i ≤ n, and to owl11:subObjectPropertyOf otherwise; SUBPROPERTYOF[dp 1 ,dp 2 ] expands to rdfs:subPropertyOf if OnlyDP(dp 1 ) = true and OnlyDP(dp 2 ) = true , and to owl11:subDataPropertyOf otherwise; EQUIVALENTPROPERTY[op 1 ,...,op n ] expands to owl:equivalentProperty if OnlyOP(op i ) = true for each 1 ≤ i ≤ n,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 datatype;
• 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
• to owl11:equivalentObjectProperty otherwise; EQUIVALENTPROPERTY[dpelt denotes an entity, an anonymous individual, or a literal.

In this section, T(SEQ y₁ ,...,dp... y_n ] expands to owl:equivalentProperty if OnlyDP(dp i) = true for each 1 ≤ i ≤ n, and to owl11:equivalentDataProperty otherwise; FUNCTIONALPROPERTY[op] expands to owl:FunctionalProperty if OnlyOP(op) = true , and to owl11:FunctionalObjectProperty otherwise; FUNCTIONALPROPERTY[dp] expands to owl:FunctionalProperty if OnlyDP(dp) = true , and to owl11:FunctionalDataProperty otherwise; DOMAIN[op] expands to rdfs:domain if OnlyOP(op) = true , and to owl11:objectPropertyDomain otherwise; DOMAIN[dp] expands to rdfs:domain if OnlyDP(dp) = true , and to owl11:dataPropertyDomain otherwise; RANGE[op] expands to rdfs:range if OnlyOP(op) = true , and to owl11:objectPropertyRange otherwise; and RANGE[dp] expands to rdfs:range if OnlyDP(dp) = true , and to owl11:dataPropertyRange otherwise. Table 2 presentsdenotes the translation of a sequence of objects from the operator T that translates an OWL 2 ontology infunctional-style syntax into a set ofan RDF triples. This table does not consider axioms with annotations: the translation of such axioms is describedlist, as shown in Section 2.1 .Table 2.1.

If ax' is translated into an OWL 2 ontology in functional-style syntaxa single RDF triple s p o, if possible.then the function Type(x) assigns a setaxiom ax generates the following triples instead of types to each resource node x in G (intriple s p o:

This and all other definitions, the graph G is implicitly understood and is not specified explicitly) andis defined asthe smallest set satisfyingcase for the conditions from Table 3. Table 3. Types of Nodes in a Graph If G containsfollowing axioms: SubClassOf, DisjointClasses with two classes, SubPropertyOf without a triple of this form... ...then Type(x) must contain this URI. xproperty chain as the subproperty expression, PropertyDomain, PropertyRange, InverseProperties, FunctionalProperty, InverseFunctionalProperty, ReflexiveProperty, IrreflexiveProperty, SymmetricProperty, AsymmetricProperty, TransitiveProperty, DisjointProperties with two properties, ClassAssertion, PropertyAssertion, Declaration, and DifferentIndividuals with two individuals.

Axioms DisjointUnion, SubPropertyOf with a subproperty chain, and HasKey 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.

If the axiom ax' is of type EquivalentClasses, EquivalentProperties, 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.

This section specifies canonical RDF parsing — a process that transforms 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 MAY implement whatever algorithm it chooses; however, the result MUST be structurally equivalent to the result of canonical RDF parsing.

Canonical RDF parsing maintains the following functions that map a 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 MUST be rejected as syntactically incorrect.

• 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.

If there is an attempt to redefine (i.e., change after the initial definition) the value of any of these functions for any x, then G MUST be rejected as syntactically incorrect.

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.

Additional 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, the maximal possible subset of G MUST be matched.

The abbreviation T(SEQ y₁ ... y_n) denotes the pattern corresponding to RDF lists, as shown in Table 3. This is the same mapping for lists as used in Table 1, but here it is used to recognize lists instead of mapping them.

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 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.

Finally, the set of declarations Decl(O) 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.4.

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 10 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 MUST be rejected as syntactically incorrect.

Next, the functions OnlyOP(x)CE, DR, OPE, DPE, and OnlyDP(x)AP are definedinitialized as follows: OnlyOP(x) is true ifshown in Table 8.

The function OPEorDPE is truedefined as follows: OPEorDPE(x) = OPE(x) if and onlyOPE(x) ≠ ε; OPEorDPE(x) = DPE(x) if owl:DatatypeProperty ∈ Type(x) and owl:ObjectPropertyDPE(x) ≠ ε; and owl:AnnotationProperty are notOPEorDPE(x) = ε otherwise.