The normative form of this document is a compound HTML document.
Copyright ©2002 W3C ^{©} ( MIT, INRIA, Keio). All Rights Reserved. W3C liability, trademark , document use and software licensing rules apply.
The OWL Web Ontology Language is being designed by the W3C Web Ontology Working Group as a revision of the DAML+OIL web ontology language. This description of OWL contains a highlevel abstract syntax for both OWL and OWL Lite, a subset of OWL. A modeltheoretic semantics is given to provide a formal meaning for OWL ontologies (or knowledge bases) written in the abstract syntax. A modeltheoretic semantics in the form of an extension to the RDFS model theory is also given to provide a formal meaning for OWL ontologies written as ntriples. A mapping from the abstract syntax to ntriples is given and the two model theories are shown to have the same consequences on OWL ontologies that can be written in the abstract syntax.
This is a W3C Web Ontology Working Group Working Draft produced 8 November 2002 as part of the W3C Semantic Web Activity (Activity Statement). It incorporates decisions made by the Working Group in designing the OWL Web Ontology Language.
This document is being released for review by W3C Members and other interested parties to encourage feedback and comments.
There are no patent disclosures related to this work at the time of this writing.
This is a public W3C Working Draft and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
Comments on this document are invited and should be sent to the public mailing list publicwebontcomments@w3.org. An archive of comments is available at http://lists.w3.org/Archives/Public/publicwebontcomments/ .
The W3C Web Ontology Working Group (WebOnt) is tasked with producing a web ontology language extending the reach of XML, RDF, and RDF Schema. This language, called OWL, is based on the DAML+OIL web ontology language [DAML+OIL].
This document contains several interrelated specifications of the several styles of OWL. First, Section 2 contains a highlevel, abstract syntax for both OWL Lite, a subset of OWL [OWL Features], and a fuller style of using OWL, sometimes called OWL/DL. This document, however, defines neither a presentation syntax nor an exchange syntax for OWL. The official exchange syntax for OWL is RDF/XML; a document defining how RDF is used to encode OWL is the subject of the OWL Reference document [OWL Reference]. A mapping from the abstract syntax to ntriples [RDF Tests] is, however, provided in Section 4.
This document contains two formal semantics for OWL. One of these semantics, defined in Section 3, is a direct, standard modeltheoretic semantics for OWL ontologies written in the abstract syntax. The other, defined in Section 5, is an extension of the RDFS modeltheoretic semantics that starts with ntriples and provides a semantics for OWL ontologies written in the official OWL exchange syntax. Two versions of this second semantics are provided, one that corresponds moreclosely to the direct semantics and one that can be used in cases where classes need to be treated as individuals. These two versions are actually very close, only differing in how they divide up the domain of discourse.
Appendix A contains a proof that the two different semantics have the same consequences on OWL ontologies that correspond to abstract OWL ontologies that separate OWL individuals, OWL classes, OWL properties, and the RDF, RDFS, and OWL structural vocabulary. For such OWL ontologies the direct model theory is authoritative and the RDFScompatible model theory is secondary.
Finally a few examples of the various concepts defined in the document are presented in Appendix B.
The language described in this document is very close to DAML+OIL. The exchange syntax for OWL, as defined in the OWL Reference document [OWL Reference], has only minor changes from DAML+OIL. Even the abstract syntax can be viewed as an abstract syntax for DAML+OIL.
The only substantive changes between OWL and DAML+OIL are
There are also a number of minor differences between OWL and DAML+OIL including a number of changes to the names of the various constructs, as mentioned in Appendix A of the OWL Reference Description [OWL Reference]. These naming changes may indicate potential changes to the preferred names in the concrete syntax for OWL, but the intent of WebOnt is to maintain the DAML+OIL names to the maximum extent reasonable.
This document takes stances on several open working group issues, some of which are detailed below. All working group issues are discussed in the issue listing document [OWL Issues].
The Joint US/EU ad hoc Agent Markup Language Committee developed DAML+OIL, which is the direct precursor to OWL. Many of the ideas in DAM+OIL and thus in OWL are also present in the Ontology Inference Layer (OIL). Many of the other members of the W3C Web Ontology Working Group have had substantial input into this document.
The description of OWL here abstracts from concrete syntax and thus facilitates access to and evaluation of the language. A highlevel syntax is used to make the language features easier to see. This particular syntax has a framelike style, where a collection of information about a class or property is given in one large syntactic construct, instead of being divided into a number of atomic chunks (as in most Description Logics) or even being divided into even more triples (as in DAML+OIL), again for ease of readability. The syntax used here is rather informal, even for an abstract syntax  in general the arguments of a construct should be considered to be unordered wherever the order would not affect the meaning of the construct.
This syntax does not have to worry about any of the problems induced by the RDF triple model, including nonclosed and illformed lists and restrictions. No parsetype extensions are needed for readability, and many issues of coordination with the RDF Core WG are not relevant at this level of syntax. Layering issues can also be safely ignored. Further, namespace issues can also be somewhat ignored; in the syntax here reserved words are not given with any namespace qualification.
The abstract syntax is specified here by means of a version of Extended BNF. In this version of BNF, terminals are not quoted, nonterminals are enclosed in pointy brackets (<…>), and alternatives are either separated by vertical bars () or are given in different productions. Elements that can occur at most once are enclosed in square brackets ([…]); elements that can occur any number of times (including zero) are enclosed in braces ({…}).
The meaning of each construct in the OWL abstract syntax is described when it is introduced. The formal meaning of these constructs is given in Section 3 via a modeltheoretic semantics.
While it is widely appreciated that all of the features in expressive languages such as OWL (and DAML+OIL) are important to some users, it is also understood that such languages may be daunting to some groups who are trying to support a tool suite for the entire language. In order to provide a target that is approachable to a wider audience, a smaller language has been defined, now referred to as OWL Lite [OWL Features]. This smaller language attempts to capture many of the commonly used features of OWL. It also attempts to describe a useful language that provides more than RDF Schema with the goal of adding functionality that is important in order to support web applications. An abstract syntax is expressed both for this smaller language and also for a fuller style of OWL.
The abstract syntax here is less general than the exchange syntax for OWL. In particular, it does not permit the construction of selfreferential syntactic constructs. It is also intended for use in cases where classes, properties, and individuals form disjoint collections. These are roughly the restrictions required to make OWL fit into the Description Logic paradigm, and thus this abstract syntax should be thought of a syntax for OWL/DL as defined in Section 5.3.1.
An OWL ontology in the abstract syntax is a sequence of axioms and facts, plus inclusion references to other ontologies, which are considered to be included in the ontology. Ontologies can also have nonlogical annotations that can be used to record authorship, and other nonlogical information associated with an ontology. OWL ontologies are web documents, and can be referenced by means of a URI.
<ontology> ::= Ontology ( {<directive>} ) <directive> ::= Annotation ( <URI reference> <URI reference> ) <directive> ::= Annotation ( <URI reference> <lexicalform> ) <directive> ::= Imports ( <URI> ) <directive> ::= <axiom> <directive> ::= <fact>
Ontologies incorporate information about classes, properties, and individuals, each of which can have an ID which is a URI reference. (It is convenient to use QNames wherever possible, turning their expansion into a URI reference, as is done in RDF.) Ontologies can also reference builtin XML Schema datatypes, by means of a URI reference for the datatype.
<datatypeID> ::= <URI reference> <classID> ::= <URI reference> <individualID> ::= <URI reference> <datavaluedPropertyID> ::= <URI reference> <individualvaluedPropertyID> ::= <URI reference>
If a URI reference is a datatype, i.e., if there is a datatype definition retrievable using the URI reference, then that URI reference cannot be used as the ID for a class. However, a URI reference can be the ID of a class or datatype as well as the ID of a property as well as the ID of an individual. Individual IDs are used to refer to resources, and typed data literals are used to refer to the XML Schema data values.
In OWL a datatype denotes the set of XML Schema data values that is the value space for the datatype. Classes denote sets of individuals. Properties relate individuals to other information, and are divided into two disjoint groups, datavalued properties and individualvalued properties. Elements of the first group of properties relate individuals to data values, elements of the second group relate individuals to other individuals.
There are two builtin classes in OWL, they both use URI references in the asyettobedetermined OWL URI, for which the namespace name owl is used here. The class with ID owl:Thing is the class of all individuals, and is part of OWL Lite. The class with ID owl:Nothing is the empty class.
Many OWL constructs use annotations, which, just like annotation directives, are used to record nonlogical information associated with some portion of the construct.
<annotation> ::= annotation ( <URI reference> <URI reference> ) <annotation> ::= annotation ( <URI reference> <lexicalform> )
There are two kinds of facts in the OWL abstract syntax. The first kind of fact states information about a particular individual, in the form of classes that the individual belongs to plus properties and values of that individual. An individual can be given an individualID that will denote that individual, and can be used to refer to that individual. However, an individual need not be given an individualID. Such individuals are anonymous (blank in RDF terms) and cannot be directly referred to elsewhere. The syntax here is set up to mirror the normal RDF/XML syntax.
<fact> ::= <individual> <individual> ::= Individual( [<individualID>] {<annotation>} {type(<type>)} {<propertyValue>} ) <propertyValue> ::= value( <individualvaluedPropertyID> <individualID> )  value( <individualvaluedPropertyID> <individual> )  value( <datavaluedPropertyID> <dataLiteral> )
Facts are the same in OWL Lite and the full abstract syntax, except for what can be a type. In OWL Lite, types can be classIDs or OWL Lite restrictions
<type> ::= <classID>  <restriction>
In the full abstract syntax types can be general descriptions, which include classIDs and OWL Lite restrictions
<type> ::= <description>
In the abstract syntax data literals consist of a datatype and the lexical representation of a data value in that datatype (a typed data literal).
<dataLiteral> ::= <typedDataLiteral> <typedDataLiteral> ::= <datatypeID> <lexicalform>
In the abstract syntax the other kinds of facts are used to make individual IDs be the same or pairwise distinct.
<fact> ::= SameIndividual( <individualID> {<individualID>} ) <fact> ::= DifferentIndividuals( <individualID> {<individualID>} )
The biggest differences between OWL Lite and the full abstract syntax show up in the axioms, which are used to provide information about classes and properties. As it is the smaller language, OWL Lite axioms are given first, and then the full abstract syntax is given as additions to OWL Lite.
Axioms are used to associate class and property IDs with either partial or complete specifications of their characteristics, and to give other logical information about classes and properties. Axioms used to be called definitions, but they are not all definitions in the common sense of the term, as has been made evident in several discussions in the WG, and thus a moreneutral name has been chosen.
The syntax used here is meant to look somewhat like the syntax used in some frame systems. Each class axiom in OWL Lite contains a collection of moregeneral classes and a collection of local property restrictions in the form of restriction constructs. The restriction construct gives the local range of a property, how many values are permitted, and/or a collection of required values. The class is made either equivalent to or a subset of the intersection of these moregeneral classes and restrictions. In the full abstract syntax a class axiom contains a collection of descriptions, which can be moregeneral classes, restrictions, sets of individuals, and boolean combinations of descriptions. Classes can also be specified by enumeration or be made the same or disjoint.
Properties can be equivalent to or subproperties of others; can be made functional, inverse functional, symmetric, or transitive; and can be given global domains and ranges. However, most information about properties is more naturally expressed in restrictions, which allow local range and cardinality information to be specified.
There is no requirement that there be an axiom for each class used in an ontology. In fact, there can be any number of axioms for each class, including none. Properties used in an abstract syntax ontology have to be categorized as either datavalued or individualvalued, so they need an axiom for this purpose at least. There is no requirement that there be at most one axiom for a class or property used in an ontology. Each axiom for a particular class (or property) ID contributes to the meaning of the class (or property).
In OWL Lite class axioms are used to state that a class is
exactly equivalent to, for the modality complete
, or a subclass of,
for the modality partial
, the conjunction of a collection of
superclasses and OWL Lite Restrictions.
<axiom> ::= Class( <classID> <modality> {<annotation>} {<super>} ) <modality> ::= complete  partial <super> ::= <classID>  <restriction>
In OWL Lite it is possible to state that two classes are the same.
<axiom> ::= EquivalentClasses( <classID> {<classID>} )
Restrictions are used in OWL Lite class axioms to provide local constraints on properties in the class. Each allValuesFrom part of a restriction makes the constraint that all values of the property for objects in the class must belong to the specified class or datatype. Each someValuesFrom part makes the constraint that there must be at least one value for the property that belongs to the specified class or datatype. The cardinality part says how many distinct values there are for the property for each individual in the class. In OWL Lite the only cardinalities allowed are 0 and 1.
There is a side condition in OWL Lite that properties that are transitive or that have transitive subproperties may not have cardinality conditions expressed on them in restrictions.
<restriction> ::= restriction( <datavaluedPropertyID> {allValuesFrom(<datatypeID>)} {someValuesFrom(<datatypeID>)} [<cardinality>] ) <restriction> ::= restriction( <individualvaluedPropertyID> {allValuesFrom(<classID>)} {someValuesFrom(<classID>)} [<cardinality>] ) <cardinality> ::= minCardinality(0)  minCardinality(1)   maxCardinality(0)  maxCardinality(1)   cardinality(0)  cardinality(1)
Properties are also specified using a framelike syntax. Properties are divided into datavalued properties, which relate individuals to data values, like integers, and individualvalued properties, which relate individuals to other individuals. Properties can be given superproperties, allowing the construction of a property hierarchy. It does not make sense to have an individual property be a superproperty of a data property, or vice versa.
Properties can also be given domains and ranges. A domain for a property specifies which individuals are potential subjects of statements that have the property as verb, just as in RDF. In OWL Lite the domains of properties are classes. Properties can have multiple domains, in which case only individuals that belong to all of the domains are potential subjects. A range for a property specifies which individuals or data values can be objects of the property. Again, properties can have multiple ranges, in which case only individuals or data values that belong to all of the ranges are potential objects. In OWL Lite ranges for individualvalued properties are classes; ranges for datavalued properties are datatypes.
Datavalued properties can be specified as (partial) functional, i.e., given an individual, there can be at most one relationship to a data value for that individual in the property. Individualvalued properties can be specified to be the inverse of another property. Individualvalued properties can also be specified to be symmetric as well as functional, inverse functional, or transitive.
Individualvalued properties that are transitive, or that have transitive subproperties, may not have cardinality conditions expressed on them, either in restrictions or by being functional, or inverse functional. This is needed to maintain the decidability of the language.
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID> {<annotation>} {super(<datavaluedPropertyID>)} {domain(<classID>)} {range(<datatypeID>)} [Functional] ) <axiom> ::= ObjectProperty ( <individualvaluedPropertyID> {<annotation>} {super(<individualvaluedPropertyID>)} {domain(<classID>)} {range(<classID>)} [inverseOf(<individualvaluedPropertyID>)] [Symmetric] [Functional  InverseFunctional  Functional InverseFunctional  Transitive] )
The following axioms make several properties be the same, or make one property be a subproperty of another.
<axiom> ::= EquivalentProperties( <datavaluedPropertyID> {<datavaluedPropertyID>} ) <axiom> ::= SubPropertyOf( <datavaluedPropertyID> <datavaluedPropertyID> ) <axiom> ::= EquivalentProperties( <individualvaluedPropertyID> {<individualvaluedPropertyID>} ) <axiom> ::= SubPropertyOf( <individualvaluedPropertyID> <individualvaluedPropertyID> )
The full abstract syntax has moregeneral versions of the OWL Lite class axioms where superclasses, moregeneral restrictions, and boolean combinations of these are allowed. Together, these constructs are called descriptions.
<axiom> ::= Class( <classID> <modality> {<annotation>} {<description>} ) <modality> ::= complete  partial
In the full abstract syntax it is also possible to make a class exactly consist of a certain set of individuals, as follows.
<axiom> ::= EnumeratedClass( <classID> {<annotation>} {<individualID>} )
Finally, in the full abstract syntax it is possible to require that a collection of descriptions be pairwise disjoint, or have the same members, or that one description is a subclass of another. Note that the last two of these axioms generalize the first kind of class axiom just above.
<axiom> ::= DisjointClasses( <description> {<description>} ) <axiom> ::= EquivalentClasses( <description> {<description>} ) <axiom> ::= SubClassOf( <description> <description> )
Descriptions in the full abstract syntax include class IDs and the restriction constructor. Descriptions can also be boolean combinations of other descriptions, and sets of individuals.
<description> ::= <classID>  <restriction>  unionOf( {<description>} )  intersectionOf( {<description>} )  complementOf( <description> )  oneOf({<individualID>} )
Restrictions in the full abstract syntax generalize OWL Lite restrictions by allowing descriptions where classes are allowed in OWL Lite and allowing sets of data values as well as datatypes. The combination of datatypes and sets of data values is called a data range. In the full abstract syntax, values can also be given for properties in classes. As well, cardinalities are not restricted to only 0 and 1.
<restriction> ::= restriction( <datavaluedPropertyID> {allValuesFrom(<dataRange>)} {someValuesFrom(<dataRange>)} {value(<dataLiteral>)} {<cardinality>} ) <restriction> ::= restriction( <individualvaluedPropertyID> {allValuesFrom(<description>)} {someValuesFrom(<description>)} {value(<individualID>)} {<cardinality>} ) <cardinality> ::= minCardinality(<nonnegativeinteger> )  maxCardinality(<nonnegativeinteger>)  cardinality(<nonnegativeinteger>)
A dataRange, used as the range of a datavalued property and in other places in the full abstract syntax, is either a datatype or a set of data values.
<dataRange> ::= <datatypeID> <dataRange> ::= oneOf({<typedDataLiteral>} )
As in OWL Lite, there is a side condition that properties that are transitive, or that have transitive subproperties, may not have cardinality conditions expressed on them in restrictions.
Property axioms in the full abstract syntax generalize OWL Lite property axioms by allowing descriptions in place of classes and data ranges in place of datatypes in domains and ranges.
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID> {<annotation>} {super(<datavaluedPropertyID>)} {domain(<description>)} {range(<dataRange>)} [Functional] ) <axiom> ::= ObjectProperty ( <individualvaluedPropertyID> {<annotation>} {super(<individualvaluedPropertyID>)} {domain(<description>)} {range(<description>)} [inverseOf(<individualvaluedPropertyID>)] [Symmetric] [Functional  InverseFunctional  Functional InverseFunctional  Transitive] )
This modeltheoretic semantics for OWL goes directly from ontologies in the abstract syntax to a standard model theory. It is much simpler than the semantics Section 5 that uses an OWL knowledge base in the form of ntriples and is an extension of the RDFS model theory.
The semantics here starts with the notion of a vocabulary, which can be thought of as the URI references that are of interest in a knowledge base. It is, however, not necessary that a vocabulary consist only of the URI references in a knowledge base.
An OWL vocabulary V is a set of URI references, including owl:Thing, owl:Nothing, and rdfs:Literal. Each OWL vocabulary also includes URI references for each of the XML Schema nonlist builtin simple datatypes. In the semantics LV is the (nondisjoint) union of the value spaces of these datatypes.
An Abstract OWL interpretation with vocabulary V is a fourtuple of the form:
I = <R, S, EC, ER>
where
S provides meaning for URI references that are used to denote OWL individuals, while EC and ER provide meaning for URI references that are used as OWL classes and OWL properties, respectively.
Abstract OWL interpretations have the following conditions having to do with datatypes:
EC is extended to the syntactic constructs of <description>s, <dataRange>s, <individual>s, and <propertyValue>s as follows:
Syntax  S  EC(S) 

owl:Thing  R 
owl:Nothing  { } 
rdfs:Literal  LV 
complementOf(c)  R  EC(c) 
unionOf(c_{1} … c_{n})  EC(c_{1}) ∪ … ∪ EC(c_{n}) 
intersectionOf(c_{1} … c_{n})  EC(c_{1}) ∩ … ∩ EC(c_{n}) 
oneOf(i_{1} … i_{n})  {S(i_{1}), …, S(i_{n})} 
oneOf(d_{1},l_{1} … d_{n},l_{n})  {D(d_{1},l_{1}), …, D(d_{n},l_{n})} 
restriction(p x_{1} … x_{n})  EC(restriction(p x_{1}))∩…∩EC(restriction(p x_{n})) 
restriction(p allValuesFrom(r))  {x ∈ R  <x,y> ∈ ER(p) → y ∈ EC(r)} 
restriction(p someValuesFrom(e))  {x ∈ R  ∃ <x,y> ∈ ER(p) ∧ y ∈ EC(e)} 
restriction(p value(i))  {x ∈ R  <x,S(i)> ∈ ER(p)} 
restriction(p value(d,l))  {x ∈ R  <x,D(d,l)> ∈ ER(p)} 
restriction(p minCardinality(n))  {x ∈ R  card({y : <x,y> ∈ ER(p)}) ≤ n} 
restriction(p maxCardinality(n))  {x ∈ R  card({y : <x,y> ∈ ER(p)}) ≥ n} 
restriction(p cardinality(n))  {x ∈ R  card({y : <x,y> ∈ ER(p)}) = n} 
Individual(annotation(…) … annotation(…) type(c_{1}) … type(c_{m}) pv_{1} … pv_{n})  EC(c_{1}) ∩ … ∩ EC(c_{m}) ∩ EC(pv(pv_{1})) ∩…∩ EC(pv(pv_{n})) 
Individual(i annotation(…) … annotation(…) type(c_{1}) … type(c_{m}) pv_{1} … pv_{n})  {S(i)} ∩ EC(c) ∩ … ∩ EC(c_{m}) ∩ EC(pv(pv_{1})) ∩…∩ EC(pv(pv_{n})) 
pv(p Individual(…))  {x ∈ R  ∃ y∈EC(Individual(…)) : <x,y> ∈ ER(p)} 
pv(p id), for id an individualID  {x ∈ R  <x,S(id)> ∈ ER(p) } 
pv(p d,l)  {x ∈ R  <x,D(d,l)> ∈ ER(p) } 
An Abstract OWL interpretation, I, is an interpretation of OWL axioms and facts as given in the table below. In the table, optional parts of axioms and facts are given in square brackets ([…]) and have corresponding optional conditions, also given in square brackets.
Directive  Conditions on interpretations 

Class(c complete annotation(…) … annotation(…) descr_{1} … descr_{n})  EC(c) = EC(descr_{1}) ∩…∩ EC(descr_{n}) 
Class(c partial annotation(…) … annotation(…) descr_{1} … descr_{n})  EC(c) ⊆ EC(descr_{1}) ∩…∩ EC(descr_{n}) 
EnumeratedClass(c annotation(…) … annotation(…) i_{1} … i_{n})  EC(c) = { S(i_{1}), …, S(i_{n}) } 
DisjointClasses(d_{1} … d_{n})  EC(d_{i}) ∩ EC(d_{j}) = { } for 1 ≤ i < j ≤ n 
EquivalentClasses(d_{1} … d_{n})  EC(d_{i}) = EC(d_{j}) for 1 ≤ i < j ≤ n 
SubClassOf(d_{1} d_{2})  EC(d_{1}) ⊆ EC(d_{2}) 
DataProperty(p annotation(…) … annotation(…) super(s_{1}) … super(s_{n}) domain(d_{1}) … domain(d_{n}) range(r_{1}) … range(r_{n}) [Functional]) 
ER(p) ⊆ ER(s_{1}) ∩…∩ ER(s_{n}) ∩ EC(d_{1})×LV ∩…∩ EC(d_{n})×LV ∩ R×EC(r_{1}) ∩…∩ R×EC(r_{n}) [ER(p) is functional] 
IndividualProperty(p annotation(…) … annotation(…) super(s_{1}) … super(s_{n}) domain(d_{1}) … domain(d_{n}) range(r_{1}) … range(r_{n}) [inverse(i)] [Symmetric] [Functional] [InverseFunctional] [Transitive]) 
ER(p) ⊆ ER(s_{1}) ∩…∩ ER(s_{n}) ∩ EC(d_{1})×R ∩…∩ EC(d_{n})×R ∩ R×EC(r_{1}) ∩…∩ R×EC(r_{n}) [ER(p) is the inverse of ER(i)] [ER(p) is symmetric] [ER(p) is functional] [ER(p) is inverse functional] [ER(p) is transitive] 
EquivalentProperties(p_{1} … p_{n})  ER(p_{i}) = ER(p_{j}) for 1 ≤ i < j ≤ n 
SubPropertyOf(p_{1} p_{2})  ER(p_{1}) ⊆ ER(p_{2}) 
SameIndividual(i_{1} … i_{n})  S(i_{j}) = S(i_{k}) for 1 ≤ j < k ≤ n 
DifferentIndividuals(i_{1} … i_{n})  S(i_{j}) ≠ S(i_{k}) for 1 ≤ j < k ≤ n 
Individual([i] annotation(…) … annotation(…) type(c_{1}) … type(c_{m}) pv_{1} … pv_{n}) 
EC(Individual([i] type(c_{1}) … type(c_{m}) pv_{1} … pv_{n})) is nonempty 
From Section 2, an OWL ontology in the abstract syntax is a sequence of axioms, facts, imports, and annotations.
The effect of an imports construct is to import the contents of another OWL ontology into the current ontology. The imported ontology is the one that can be found by accessing the document at the URI that is the argument of the imports construct. The imports closure of an OWL ontology is then the result of adding the contents of imported ontologies into the current ontology. If these contents contain further imports constructs, the process is repeated as necessary. A particular ontology is never imported more than once in this process, so loops can be handled.
Annotations have no effect on the semantics of OWL ontologies in the abstract syntax.
An Abstract OWL interpretation, I, is an interpretation of an OWL ontology, O, iff I is an interpretation of each axiom and fact in the imports closure of O.
An Abstract OWL ontology entails an OWL axiom or fact if each interpretation of the ontology is also an interpretation of the axiom or fact. An Abstract OWL ontology entails another Abstract OWL ontology if each interpretation of the first ontology is also an interpretation of the second ontology. Note that there is no need to create the imports closure of an ontology  any method that correctly determines the entailment relation is allowed.
The exchange syntax for OWL is RDF/XML, as specified in the OWL Reference Description [OWL Reference]. Further, the meaning of an OWL document base in RDF/XML is determined only from the ntriples [RDF Tests] that result from the RDF parsing of the RDF/XML document. Thus one way of translating an OWL ontology in abstract syntax form into the exchange syntax is by giving a transformation of each directive into a collection of ntriples.
The ntriples syntax used here is the one used in the RDF Model Theory [RDF MT]. In this variant, QNames are allowed. To turn this syntax into the standard one, just turn the QName into the obvious URI reference. The only prefixes used in the transformation are rdf, rdfs, xsd, and owl, which should be expanded into http://www.w3.org/1999/02/22rdfsyntaxns#, http://www.w3.org/2000/01/rdfschema#, http://www.w3.org/2001/XMLSchema#, and http://www.w3.org/2002/07/owl#, respectively.
As all OWL Lite constructs are special cases of constructs in the full abstract syntax, transformations are only provided for the full versions.
Each type of directive is translated via one of the transformation rules below. In the transformation rules nonterminals are enclosed in angle brackets. Repeating nonterminals are listed using ellipses, as in <description_{1}> … <description_{n}>, this form allows easy specification of the transformation for all values of n, including 0. Optional portions of the abstract syntax (enclosed in square brackets) are optional portions of the transformation (signified by square brackets).
The table below gives the transformation rules that transform the abstract syntax to the OWL exchange syntax. The left column gives a piece of syntax (S), the center column gives its transformation (T(S)), and the right column gives a node identifier that is the main node of the transformation (M(T(S))), but only for syntactic constructs that can occur as pieces of directives. Some transformations in the table are for directives. Other transformations are for parts of directives. The last transformation is for sequences, which are not part of the abstract syntax per se. This last transformation is used to make some of the other transformations more compact and easier to read.
For many directives these transformation rules call for the transformation of components of the directive using other transformation rules. When the transformation of a component is used in a node position of a triple, the transformation of the construct is part of the production (but only once per production) and the main node of that transformation should be used for that node of the triple.
Bnode identifiers here must be taken as local to each transformation, i.e., different identifiers should be used for each invocation of a transformation rule.
Abstract Syntax (and sequences)  S  Transformation  T(S)  Main Node  M(T(S)) 
<datatypeID>  <datatypeID> rdf:type owl:Datatype . <datatypeID> rdf:subClassOf rdfs:Literal . 
<datatypeID> 
<classID>  <classID> rdf:type owl:Class . <classID> rdf:subClassOf owl:Thing . 
<classID> 
<individualID>  <individualID> rdf:type owl:Thing .  <individualID> 
<datavaluedPropertyID>  <datavaluedPropertyID> rdf:type owl:DatatypeProperty . <datavaluedPropertyID> rdfs:domain owl:Thing . <datavaluedPropertyID> rdfs:range rdfs:Literal . 
<datavaluedPropertyID> 
<individualvaluedPropertyID>  <individualvaluedPropertyID> rdf:type owl:ObjectProperty . <individualvaluedPropertyID> rdfs:domain owl:Thing . <individualvaluedPropertyID> rdfs:range owl:Thing . 
<individualvalued PropertyID> 
<datatypeID> <literal>  <datatypeID>:<literal> [[To be fixed.]]  <datatypeID>:<literal> 
Annotation( <URI reference> <URI reference> )  # <URI reference> <URI reference> .  
Annotation( <URI reference> <lexicalform> )  # <URI reference> <lexicalform> .  
Imports(<URI>)  # owl:imports <URI> .  
Individual(<iID> <annotation_{1}> … <annotation_{n}> type(<type_{1}>)…type(<type_{n}>) (<pID_{1}> <value_{1}>) … (<pID_{n}> <value_{n}>)) 
<iID> rdf:type T(owl:Thing) . <iID> T(<annotation_{1}>) . … <iID> T(<annotation_{n}>) . <iID> rdf:type T(<type_{1}>) . … <iID> rdf:type T(<type_{n}>) . <iID> <pID_{1}> T(<value_{1}>) . … <iID> <pID_{n}> T(<value_{n}>) . 
<iID> 
Individual( <annotation_{1}> … <annotation_{n}> type(<type_{1}>)…type(<type_{n}>) (<pID_{1}> <value_{1}>) … (<pID_{n}> <value_{n}>)) 
_:x rdf:type T(owl:Thing) . _:x T(<annotation_{1}>) . … _:x T(<annotation_{n}>) . _:x rdf:type T(<type_{1}>) . … _:x rdf:type T(<type_{n}>) . _:x <pID_{1}> T(<value_{1}>) . … _:x <pID_{n}> T(<value_{n}>) . 
_:x 
SameIndividual( <individualID_{1}> … <individualID_{n}>)  <individualID_{i}> owl:sameAs <individualID_{j}> . 1≤i<j≤n  
DifferentIndividuals(<individualID_{1}> … <individualID_{n}>)  <individualID_{i}> owl:differentFrom <individualID_{j}> . 1≤i<j≤n  
Class(<classID> [partial  complete] <annotation_{1}> … <annotation_{n}>) <description_{1}> … <description_{n}>) 
<classID> rdf:type owl:Class . <classID> [ rdfs:subClassOf  owl:sameClassAs ] _:x . _:x T(<annotation_{1}>) . … _:x T(<annotation_{n}>) . _:x owl:intersectionOf T(SEQ <description_{1}>…<description_{n}>) . 

EnumeratedClass(<classID> <annotation_{1}> … <annotation_{n}>) <individualID_{1}> … <individualID_{n}>) 
<classID> rdf:type owl:Class . <classID> owl:sameClassAs _:x . _:x T(<annotation_{1}>) . … _:x T(<annotation_{n}>) . _:x owl:oneOf T(SEQ <individualID_{1}>…<individualID_{n}>) . 

DisjointClasses( <description_{1}> … <description_{n}> )  T(<description_{i}>) owl:disjointWith T(<description_{j}>) . 1≤i<j≤n  
EquivalentClasses( <description_{1}> … <description_{n}>)  T(<description_{i}>) owl:sameClassAs T(<description_{j}>) . 1≤i<j≤n  
SubClassOf( <description_{1}> <description_{2}>)  T(<description_{1}>) rdfs:subClassOf T(<description_{2}>) .  
unionOf( <description_{1}> … <description_{n}>)  _:x owl:unionOf T(SEQ <description_{1}>…<description_{n}>) .  _:x 
intersectionOf( <description_{1}> … <description_{n}>)  _:x owl:intersectionOf T(SEQ <description_{1}>…<description_{n}>) .  _:x 
complementOf(<description>)  _:x owl:complementOf T(<description>) .  _:x 
oneOf( <individualID_{1}> … <individualID_{n}>) 
_:x rdf:type owl:Class . _:x owl:oneOf T(SEQ <individualID_{1}>…<individualID_{n}>) . 
_:x 
oneOf( <datatypeID_{1}> <value_{1}> … <datatypeID_{n}> <value_{n}>) 
_:x rdf:type owl:Datatype . _:x owl:oneOf T(SEQ <datatypeID_{1}> <value_{1}>… <datatypeID_{n}> <value_{n}>) . 
_:x 
restriction( <ID> <component_{1}> … <component_{n}>)  _:x owl:intersectionOf T(SEQ(restriction(<ID> <component_{1}>)… restriction(<ID> <component_{n}>))) . 
_:x 
restriction( <ID> allValuesFrom(<range>))  _:x rdf:type owl:Restriction . _:x owl:onProperty T(<ID>) . _:x owl:allValuesFrom T(<range>) . 
_:x 
restriction( <ID> someValuesFrom(<required>))  _:x rdf:type owl:Restriction . _:x owl:onProperty T(<ID>) . _:x owl:someValuesFrom T(<required>) . 
_:x 
restriction( <ID> value(<value>))  _:x rdf:type owl:Restriction . _:x owl:onProperty T(<ID>) . _:x owl:hasValue T(<value>) . 
_:x 
restriction( <ID> minCardinality(<min>))  _:x rdf:type owl:Restriction . _:x owl:onProperty T(<ID>) . _:x owl:minCardinality xsd:decimal"<min>" . 
_:x 
restriction( <ID> maxCardinality(<max>))  _:x rdf:type owl:Restriction . _:x owl:onProperty T(<ID>) . _:x owl:maxCardinality xsd:decimal"<max>" . 
_:x 
restriction( <ID> cardinality(<card>))  _:x rdf:type owl:Restriction . _:x owl:onProperty T(<ID>) . _:x owl:cardinality xsd:decimal"<card>" . 
_:x 
DatatypeProperty( <name> <annotation_{1}> … <annotation_{n}>) super(<super_{1}>)… super(<super_{n}>) domain(<domain_{1}>)… domain(<domain_{n}>) range(<range_{1}>)… range(<range_{n}>) [Functional]) 
<name> rdf:type owl:DatatypeProperty . <name> rdfs:domain owl:Thing . <name> rdfs:range rdfs:Literal . <name> T(<annotation_{1}>) . … <name> T(<annotation_{n}>) . <name> rdfs:subPropertyOf T(<super_{1}>) . … <name> rdfs:subPropertyOf T(<super_{n}>) . <name> rdfs:domain T(<domain_{1}>) . … <name> rdfs:domain T(<domain_{n}>) . <name> rdfs:range T(<range_{1}>) . … <name> rdfs:range T(<range_{n}>) . [<name> rdf:type owl:FunctionalProperty . ] 

ObjectProperty( <name> <annotation_{1}> … <annotation_{n}>) super(<super_{1}>)… super(<super_{n}>) domain(<domain_{1}>)… domain(<domain_{n}>) range(<range_{1}>)… range(<range_{n}>) [inverseOf(<inverse>)] [Symmetric] [Functional  InverseFunctional  Transitive]) 
<name> rdf:type owl:ObjectProperty . <name> rdfs:domain owl:Thing . <name> rdfs:range owl:Thing . <name> T(<annotation_{1}>) . … <name> T(<annotation_{n}>) . <name> rdfs:subPropertyOf T(<super_{1}>) . … <name> rdfs:subPropertyOf T(<super_{n}>) . <name> rdfs:domain T(<domain_{1}>) . … <name> rdfs:domain T(<domain_{n}>) . <name> rdfs:range T(<range_{1}>) . … <name> rdfs:range T(<range_{n}>) . [<name> owl:inverseOf T(<inverse>) .] [<name> rdf:type owl:SymmetricProperty . ] [<name> rdf:type owl:FunctionalProperty . ] [<name> rdf:type owl:InverseFunctionalProperty . ] [<name> rdf:type owl:TransitiveProperty . ] 

EquivalentProperties( <datavaluedPropertyID_{1}> … <datavaluedPropertyID_{n}>)  T(<datavaluedPropertyID_{i}>) owl:samePropertyAs T(<datavaluedPropertyID_{j}>) . 1≤i<j≤n  
SubPropertyOf( <datavaluedPropertyID_{1}> <datavaluedPropertyID_{2}>)  T(<datavaluedPropertyID_{1}>) rdfs:subPropertyOf T(<datavaluedPropertyID_{2}>) .  
EquivalentProperties( <individualvaluedPropertyID_{1}> … <individualvaluedPropertyID_{n}>)  T(<individualvaluedPropertyID_{i}>) owl:samePropertyAs T(<individualvaluedPropertyID_{j}>) . 1≤i<j≤n  
SubPropertyOf( <individualvaluedPropertyID_{1}> <individualvaluedPropertyID_{2}>)  T(<individualvaluedPropertyID_{1}>) rdfs:subPropertyOf T(<individualvaluedPropertyID_{2}>) .  
annotation ( <URI reference> <URI reference> )  <URI reference> <URI reference>  
annotation ( <URI reference> <lexicalform> )  <URI reference> "<lexicalform>"  
SEQ <item_{1}>…<item_{n}>  _:l_{1} rdf:type rdf:List . _:l_{1} rdf:first T(<item_{1}>) . _:l_{1} rdf:rest _:l_{2} . … _:ln rdf:type rdf:List . _:ln rdf:first T(<item_{n}>) . _:ln rdf:rest rdf:nil . 
_:l_{1} 
A collection of ntriples is an OWL/DL ontology in ntriple form if it is the result of the above transformation of an OWL ontology in abstract syntax form and, moreover,
This transformation is not injective, as several OWL abstract ontologies that do not use the above reserved vocabulary can map into the same collection of triples. However, the only cases where this can happen is with constructs that have the same meaning, such as several DisjointClasses axioms having the same effect as one larger one. It would be possible to define a canonical inverse transformation, if desired.
This modeltheoretic semantics for OWL is upwardcompatible with the RDFS semantics as defined in the RDF model theory [RDF MT].
All of the OWL vocabulary is defined on the 'OWL universe', which is a collection of RDFS classes that are intended to circumscribe the domain of application of the OWL vocabulary: owl:Thing, owl:Class and owl:Property. The RDFS class extension of owl:Thing comprises the individuals of the OWL universe. The RDFS class extension of owl:Class comprises the classes of the OWL universe. The RDFS class extension of owl:Property comprises the properties of the OWL universe.
There are two different styles of using OWL. In the more freewheeling style, called OWL/Full here, these three classes are identified with their RDFS counterparts. In OWL/Full, as in RDFS, resources can be both an individual and a class, or, in fact, even an individual, a class, and a property. In the more restrictive style, called OWL/DL here, these three classes are different from their RDFS counterparts and, moreover, pairwise disjoint.
The OWL/DL style gives up some expressive power in return for decidability of entailment. Further, OWL/DL can be processed by efficient DL reasoners. Both styles of OWL provide entailments that are missing in a naive translation of the DAML+OIL modeltheoretic semantics into the RDFS semantics.
The chief differences in practice between the two styles lie in the care that is required to ensure that URI references are actually in the appropriate OWL universe. In OWL/Full, no care is needed, as the OWL universe is the same as the RDFS universe. In OWL/DL, typing information must be provided for many of the URI references used. These localizing assumptions are all trivially true in OWL/Full, and can also be ignored when one uses the OWL abstract syntax. But when writing OWL/DL in ntriples close attention must be paid to which parts of the vocabulary can be 'legally' used to refer to things in the OWL universe.
Throughout this section qualified names are used as shorthand for URI
references.
The namespace identifiers used in such names, namely rdf, rdfs, xsd,
and owl, should be used as if they are given their usual definitions.
Throughout this section
VRDFS is the RDF and RDFS builtin vocabulary,
i.e., rdf:type, rdf:Property, rdfs:Class, rdfs:subClassOf, …,
minus rdfs:Literal; and
VOWL is the OWL builtin vocabulary,
i.e., owl:Class, owl:onProperty, …,
minus owl:Thing and owl:Nothing.
Throughout this section D will be a datatyping scheme, i.e., a set of URI references, the datatypes of D, that have class extensions that are subsets of LV and mappings from literal strings to elements of their class extension. A typed literal string is a pair, d,s, consisting of a datatype and a literal string. For d,s a typed literal string, D(d,s) is the element of LV that is the literal value for string s in datatype d.
The semantics of OWL/DL and OWL/Full are very similar. The common portion of their semantics is thus given first, and the differences left until later.
From the RDF model theory [RDF MT], for V a set of URI references containing the RDF and RDFS vocabulary, an RDFS interpretation over V is a triple I = < R_{I}, EXT_{I}, S_{I} >. Here R_{I} is the domain of discourse or universe, i.e., a set that contains the denotations of URI references. EXT_{I} is used to give meaning to properties, and is a mapping from R_{I} to sets of pairs over R_{I} × (R_{I}∪LV). Finally, S_{I} is a mapping from V to R_{I} that takes a URI reference to its denotation. CEXT_{I} is then defined as CEXT_{I}(c) = { x∈R_{I}  <x,c>∈EXT_{I}(S_{I}(rdf:type)) }. RDFS interpretations must meet several conditions, as detailed in the RDFS model theory. For example, S_{I}(rdfs:subClassOf) must be a transitive relation.
An OWL interpretation, I = < R_{I}, EXT_{I}, S_{I} >, over a vocabulary V, where V includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing, is an RDFS interpretation over V that satisfies the following conditions:
Relationships between OWL classes
If E is  then CEXT_{I}(S_{I}(E))=  with 

owl:Thing  IOT  IOT⊆R_{I} 
owl:Nothing  {}  
rdfs:Literal  LV  
owl:Class  IOC  IOC⊆CEXT_{I}(S_{I}(rdfs:Class)) 
owl:Restriction  IOR  IOR⊆IOC 
owl:Datatype  IDC  IDC⊆CEXT_{I}(S_{I}(rdfs:Class)) 
owl:Property  IOP  IOP⊆CEXT_{I}(S_{I}(rdf:Property)) 
owl:ObjectProperty  IOOP  IOOP⊆IOP 
owl:DataTypeProperty  IODP  IODP⊆IOP 
rdf:List  IL  IL⊆R_{I} 
Membership in OWL classes
If E is  then S_{I}(E)∈ 

owl:Thing  IOC 
owl:Nothing  IOC 
rdfs:Literal  IDC 
a datatype of D  IDC 
rdf:nil  IL 
Characteristics of members of OWL classes
If E is  then if e∈CEXT_{I}(S_{I}(E)) then 

owl:Class  CEXT_{I}(e)⊆IOT 
owl:Datatype  CEXT_{I}(e)⊆LV 
owl:ObjectProperty  EXT_{I}(e)⊆IOT×IOT 
owl:DatatypeProperty  EXT_{I}(e)⊆IOT×LV 
The next constraints are IFF, which may be harder to deal with in OWL/DL, as they extend the various categories of properties to all of owl:Property. However, in OWL/DL ontologies you can neither state that an owl:DatatypeProperty is inverse functional nor ask whether it is, so there should be not adverse consequences.
If E is  then c∈CEXT_{I}(S_{I}(E)) iff c∈IOP and 

owl:SymmetricProperty  <x,y> ∈ EXT_{I}(c) → <y, x>∈EXT_{I}(c) 
owl:FunctionalProperty  <x,y_{1}> and <x,y_{2}> ∈ EXT_{I}(c) → y_{1} = y_{2} 
owl:InverseFunctionalProperty  <x_{1},y>∈EXT_{I}(c) ∧ <x_{2},y>∈EXT_{I}(c) → x_{1} = x_{2} 
owl:TransitiveProperty  <x,y>∈EXT_{I}(c) ∧ <y,z>∈EXT_{I}(c) → <x,z>∈EXT_{I}(c) 
RDFS domains and ranges are strengthened to ifandonlyif over the OWL universe.
If E is  then for  <x,y>∈CEXT_{I}(S_{I}(E)) iff 

rdfs:domain  x∈IOP,y∈IOC  <z,w>∈EXT_{I}(x) → z∈CEXT_{I}(y) 
rdfs:range  x∈IOP,y∈IOC∪IDC  <w,z>∈EXT_{I}(x) → z∈CEXT_{I}(y) 
Some OWL properties have iff characterizations
If E is  then <x,y>∈EXT_{I}(S_{I}(E)) iff 

owl:sameClassAs  x,y∈IOC ∧ CEXT_{I}(x)=CEXT_{I}(y) 
owl:disjointWith  x,y∈IOC ∧ CEXT_{I}(x)∩CEXT_{I}(y)={} 
owl:samePropertyAs  x,y∈IOP ∧ EXT_{I}(x) = EXT_{I}(y) 
owl:inverseOf  x,y∈IOOP ∧ <u,v>∈EXT_{I}(x) iff <v,u>∈EXT_{I}(y) 
owl:sameIndividualAs  x = y 
owl:sameAs  x = y 
owl:differentFrom  x ≠ y 
Some OWL properties have onlyif characterizations
We will say that l_{1} is a sequence of
y_{1},…,y_{n} over C iff
n=0 and l_{1}=S_{I}(rdf:nil)
or n>0 and l_{1}∈IL and
∃ l_{2}, …, l_{n} ∈ IL such that
<l_{1},y_{1}>∈EXT_{I}(S_{I}(rdf:first)), y_{1}∈CEXT_{I}(C),
<l_{1},l_{2}>∈EXT_{I}(S_{I}(rdf:rest)), …,
<l_{n},y_{n}>∈EXT_{I}(S_{I}(rdf:first)), y_{n}∈CEXT_{I}(C), and
<l_{n},S_{I}(rdf:nil)>∈EXT_{I}(S_{I}(rdf:rest)).
If E is  then if <x,y>∈EXT_{I}(S_{I}(E)) then 

owl:complementOf  x,y∈ IOC and CEXT_{I}(x)=IOTCEXT_{I}(y) 
If E is  then if <x,l>∈EXT_{I}(S_{I}(E)) then 

owl:unionOf  x∈IOC and l is a sequence of y_{1},…y_{n} over IOC and CEXT_{I}(x) = CEXT_{I}(y_{1})∪…∪CEXT_{I}(y_{n}) 
owl:intersectionOf  x∈IOC and l is a sequence of y_{1},…y_{n} over IOC and CEXT_{I}(x) = CEXT_{I}(y_{1})∩…∩CEXT_{I}(y_{n}) 
owl:oneOf  x∈CEXT_{I}(rdfs:Class) and l is a sequence of y_{1},…y_{n} over R_{I}∪LV and CEXT_{I}(x) = {y_{1},..., y_{n}} 
If E is  and  then if <x,l>∈EXT_{I}(S_{I}(E)) then 

owl:oneOf  l is a sequence of y_{1},…y_{n} over LV  x∈IDC and CEXT_{I}(x) = {y_{1},..., y_{n}} 
owl:oneOf  l is a sequence of y_{1},…y_{n} over IOT  x∈IOC and CEXT_{I}(x) = {y_{1},..., y_{n}} 
If  then x∈IOR, y∈IOC, p∈IOP, and CEXT_{I}(x) = 

<x,y>∈EXT_{I}(S_{I}(owl:allValuesFrom))) ∧ <x,p>∈EXT_{I}(S_{I}(owl:onProperty))) 
{u∈IOT  <u,v>∈EXT_{I}(p) → v∈CEXT_{I}(y) } 
<x,y>∈EXT_{I}(S_{I}(owl:someValuesFrom))) ∧ <x,p>∈EXT_{I}(S_{I}(owl:onProperty))) 
{u∈IOT  ∃ <u,v>∈EXT_{I}(p) ∧ v∈CEXT_{I}(y) } 
<x,y>∈EXT_{I}(S_{I}(owl:hasValue))) ∧ <x,p>∈EXT_{I}(S_{I}(owl:onProperty))) 
{u∈IOT  <u, y>∈EXT_{I}(p) } 
If  then x∈IOR, y∈LV, y is a nonnegative integer, p∈IOP, and CEXT_{I}(x) = 
<x,y>∈EXT_{I}(S_{I}(owl:minCardinality))) ∧ <x,p>∈EXT_{I}(S_{I}(owl:onProperty))) 
{u∈IOT  card({v : <u,v>∈EXT_{I}(p)}) ≥ y } 
<x,y>∈EXT_{I}(S_{I}(owl:maxCardinality))) ∧ <x,p>∈EXT_{I}(S_{I}(owl:onProperty))) 
{u∈IOT  card({v : <u,v>∈EXT_{I}(p)}) ≤ y } 
<x,y>∈EXT_{I}(S_{I}(owl:cardinality))) ∧ <x,p>∈EXT_{I}(S_{I}(owl:onProperty))) 
{u∈IOT  card({v : <u,v>∈EXT_{I}(p)}) = y } 
R_{I} contains elements corresponding to all possible OWL descriptions and data ranges
The first three conditions require the existence of the finite sequences that are used in some OWL constructs. The remaining conditions require the existence of the OWL descriptions and data ranges.
If there exists  then there exists l_{1},…,l_{n} ∈ IL with 

x_{1}, …, x_{n} ∈ IOC  <l_{1},x_{1}> ∈ EXT_{I}(S_{I}(rdf:first)),
<l_{1},l_{2}> ∈ EXT_{I}(S_{I}(rdf:rest)), … <l_{n},x_{n}> ∈ EXT_{I}(S_{I}(rdf:first)), <l_{n},S_{I}(rdf:nil)> ∈ EXT_{I}(S_{I}(rdf:rest)) 
x_{1}, …, x_{n} ∈ IOT∪LV  <l_{1},x_{1}> ∈ EXT_{I}(S_{I}(rdf:first)),
<l_{1},l_{2}> ∈ EXT_{I}(S_{I}(rdf:rest)), … <l_{n},x_{n}> ∈ EXT_{I}(S_{I}(rdf:first)), <l_{n},S_{I}(rdf:nil)> ∈ EXT_{I}(S_{I}(rdf:rest)) 
If there exists  then there exists y with 

l, a sequence of x_{1},…,x_{n} over IOC  y∈IOC, <y,l> ∈ EXT_{I}(S_{I}(owl:unionOf)) 
l, a sequence of x_{1},…,x_{n} over IOC  y∈IOC, <y,l> ∈ EXT_{I}(S_{I}(owl:intersectionOf)) 
l, a sequence of x_{1},…,x_{n} over IOT∪LV  y∈CEXT_{I}(S_{I}(rdfs:Class)), <y,l> ∈ EXT_{I}(S_{I}(owl:oneOf)) 
If there exists  then there exists y ∈ IOC with 
x ∈ IOC  <y,x> ∈ EXT_{I}(S_{I}(owl:complementOf)) 
If there exists  then there exists y ∈ IOR with 
x ∈ IOP ∧ w ∈ IOC ∪ IDC  <y,x> ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ <y,w> ∈ EXT_{I}(S_{I}(owl:allValuesFrom)) 
x ∈ IOP ∧ w ∈ IOC ∪ IDC  <y,x> ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ <y,w> ∈ EXT_{I}(S_{I}(owl:someValuesFrom)) 
x ∈ IOP ∧ w ∈ IOT ∪ LV  <y,x> ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ <y,w> ∈ EXT_{I}(S_{I}(owl:hasValue)) 
x ∈ IOP ∧ w ∈ LV ∧ w is a nonnegative integer  <y,x> ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ <y,w> ∈ EXT_{I}(S_{I}(owl:minCardinality)) 
x ∈ IOP ∧ w ∈ LV ∧ w is a nonnegative integer  <y,x> ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ <y,w> ∈ EXT_{I}(S_{I}(owl:maxCardinality)) 
x ∈ IOP ∧ w ∈ LV ∧ w is a nonnegative integer  <y,x> ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ <y,w> ∈ EXT_{I}(S_{I}(owl:cardinality)) 
OWL/DL augments the above conditions with a separation of the domain of discourse into several disjoint parts. This separation has two consequences. First, the OWL portion of the domain of discourse becomes standard firstorder, in that predicates (classes and properties) and objects are disjoint. Second, the OWL portion of a OWL/DL interpretation can be viewed as a Description Logic interpretation for a particular expressive Description Logic.
A OWL/DL interpretation over a vocabulary V', where V' includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing, is an OWL interpretation as above that satisfies the following conditions.
The domain of discourse is divided up into several pieces.
LV, IOT, IOC, IDC, IOP, and IL are all pairwise disjoint. 
There is a disjoint partition of IOP into IOOP and IODP. 
For n ∈ VRDFS∪VOWL  {rdf:nil}, S_{I}(n) ∈ R_{I}  (LV∪IOT∪IOC∪IDC∪IOP∪IL). 
Now entailment in OWL/DL can be defined.
Let K be an RDF graph and let V be a vocabulary that includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing. An OWL/DL interpretation of K is an OWL/DL interpretation over V that is also an RDFS interpretation of K.
Let K be a set of ntriples. The imports closure of K is the smallest superset of K such that if the imports closure of K contains a triple of the form x owl:imports y . where x is the empty URI and y is any URI then the imports closure of K contains the ntriples resulting from the RDF parsing of the document, if any, accessible at y into ntriples.
Let K and Q be collections of ntriples and let V be a vocabulary that includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing. Then K OWL/DL entails Q whenever all OWL/DL interpretations of the RDF graph specified by imports closure of K are also OWL/DL interpretations of the RDF graph specified by imports closure of Q.
One way to automatically obtain typing information for the vocabulary is to use translations into ntriples of certain kinds of OWL ontologies in the abstract syntax, as such translations contain information on which kind of entity a URI reference denotes. This is made more formal below.
A separated OWL vocabulary, V', is a set of URI references with a disjoint partition V' = < VI, VC, VD, VOP, VDP >, where owl:Thing and owl:Nothing are in VC, rdfs:Literal is in VD, and all the elements of D are in VD. Further V' is disjoint from VRDFS∪VOWL.
An OWL abstract ontology with separated names over a separated OWL vocabulary V' = < VI, VC, VD, VOP, VDP > is a set of OWL axioms and facts in the abstract syntax without annotations as in Section 2 where <individualID>s are taken from VI, <classID>s are taken from VC, <datatypeID>s are taken from VD, <individualvaluedPropertyIDs> are taken from VOP, and <datavaluedPropertyID>s are taken from VDP.
Let T be the mapping from OWL ontologies in the abstract syntax to ntriples. Let V' = < VI, VC, VD, VOP, VDP > be a separated OWL vocabulary. Let K and Q be OWL abstract syntax ontologies with separated names over V' and let V = V' ∪ VRDFS ∪ VOWL. Then it is the case that K entails Q if and only if T(K) OWL/DL entails T(Q). The proof is contained in Appendix A.1.
OWL/Full augments the common conditions with conditions that force the OWL and RDFS universes to be the same.
A OWL/Full interpretation over a vocabulary V, where V includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing, is an OWL interpretation as above that satisfies the following conditions.
IOT = R_{I} 
IOC = CEXT_{I}(S_{I}(rdfs:Class)) 
IOP = CEXT_{I}(S_{I}(rdf:Property)) 
OWL/Full entailment is defined in same manner as OWL/DL entailment.
Let K,C be collections of ntriples such that each of K, C, and K∪C is the translation of some OWL ontology in the abstract syntax with separated vocabulary. Then K OWL/Full entails C if K OWL/DL entails C. An initial sketch of the proof is contained in Appendix A.2.
This appendix contains proofs of theorems contained in the document.
This section shows that the two semantics for OWL/DL correspond on certain OWL knowledge bases. One semantics used in this section is the direct model theory for abstract OWL knowledge bases given in the direct modeltheoretic semantics section of this document. The other semantics is the extension of the RDFS semantics given in the RDFScompatible modeltheoretic semantics section of this document.
Throughout this section qualified names are used as shorthand for URI
references.
The namespace identifiers used in such names, namely rdf, rdfs, xsd,
and owl, should be used as if they are given their usual definitions.
Throughout this section
VRDFS is the RDF and RDFS builtin vocabulary,
i.e., rdf:type, rdf:Property, rdfs:Class, rdfs:subClassOf, …,
minus rdfs:Literal; and
VOWL is the OWL builtin vocabulary,
i.e., owl:Class, owl:onProperty, …,
minus owl:Thing and owl:Nothing.
Throughout this section D will be a datatyping scheme, i.e., a set of
URI references that have class extensions that are subsets of LV and
mappings from strings to elements of their class extension.
Throughout this section T will be the mapping from OWL abstract
knowledge bases to ntriples.
A separated OWL vocabulary is a set of URI references V with a disjoint partition V = <VI, VC, VD, VOP, VDP>, where owl:Thing and owl:Nothing are in VC, rdfs:Literal is in VD, and all the elements of D are in VD. Further V is disjoint from VRDFS∪VOWL.
An OWL abstract KB with separated names over a separated OWL vocabulary V = <VI, VC, VD, VOP, VDP> is a set of OWL axioms and facts without annotations as in Section 2 where <individualID>s are taken from VI, <classID>s are taken from VC, <datatypeID>s are taken from VD, <individualvaluedPropertyIDs> are taken from VOP, and <datavaluedPropertyID>s are taken from VDP.
Let V = <VI, VC, VD, VOP, VDP> be a separated OWL vocabulary. Then T(V) is the set of ntriples that contains exactly <v,rdf:type,owl:Thing > for v ∈ VI, <v,rdf:type,owl:Class > for v ∈ VC, <v,rdf:type,owl:Datatype > for v ∈ VD, <v,rdf:type,owl:ObjectProperty > for v ∈ VOP, and <v,rdf:type,owl:DatatypeProperty > for v ∈ VDP.
The theorem to be proved is:
Let V' be a separated OWL vocabulary.
Let K,Q be abstract OWL knowledge bases with separated names over V'.
Then K OWL entails Q iff T(K),T(V') OWL/DL entails T(Q).
Actually, a slightly stronger correspondence can be shown, but this is enough for now, as the presence of annotations and imports causes even more complications.
Let V' = <VI, VC, VD, VOP, VDP> be a separated OWL vocabulary.
Let V = VI ∪ VC ∪ VD ∪ VOP ∪ VDP ∪ VRDFS ∪ VOWL.
Let I'= <R,S,EC,ER> be an abstract OWL interpretation over V'.
Let I = <R_{I},S_{I},EXT_{I}>
be an OWL/DL interpretation over V of T(V').
Let CEXT_{I} have its usual meaning.
If R=CEXT_{I}(S_{I}(owl:Thing)),
S(v)=S_{I}(v) for v ∈ VI,
EC(v)=CEXT_{I}(S_{I}(v)) for v∈VC∪VD, and
ER(v)=EXT_{I}(S_{I}(v)) for v∈VOP∪VDP
then for d any abstract OWL description or data range over V',
I OWL/DL satisfies T(d) and
for any E mapping all the blank nodes of T(d) into R_{I}
where I+E OWL/DL satisfies T(d),
Proof
The proof of the lemma is by a structural induction. Throughout the proof, let IOT = CEXT_{I}(S_{I}(owl:Thing)), IOC = CEXT_{I}(S_{I}(owl:Class)), IDC = CEXT_{I}(S_{I}(owl:Datatype)), IOOP = CEXT_{I}(S_{I}(owl:ObjectProperty)), IODP = CEXT_{I}(S_{I}(owl:DatatypeProperty)), and IL = CEXT_{I}(S_{I}(rdf:List)).
To make the induction work, it is necessary to show that for any d a description or data range with subconstructs the ntriples of T(d) contains ntriples for each of the subconstructs that do not share any blank nodes with ntriples from the other subconstructs. This can easily be verified from the rules for T.
If p∈VOP then I satisfies p∈IOOP. Then, as I is an OWL/DL interpretation, I satisfies <p,S_{I}(owl:Thing)>∈EXT_{I}(S_{I}(rdfs:domain)) and <p,S_{I}(owl:Thing)>∈EXT_{I}(S_{I}(rdfs:range)). Thus I satisfies T(p). Similarly for p∈VDP.
Let V', V, I', and I be as in Lemma 1. Let D be an OWL directive over V'. Then I satisfies T(D) iff I' satisfies D.
Proof
Let d=intersectionOf(d_{1} … d_{n}). As d is a description over V', thus I satisfies T(d) and for any E mapping the blank nodes of T(d) such that I+E satisfies T(d), CEXT_{I}(I+E(M(T(d)))) = EC(d). Thus for some E mapping the blank nodes of T(d) such that I+E satisfies T(d), CEXT_{I}(I+E(M(T(d)))) = EC(d) and I+E(M(T(d))∈IOC.
If I' satisfies D then EC(foo) = EC(d). From above, there is some E such that CEXT_{I}(I+E(M(T(d)))) = EC(d) = EC(foo) = CEXT_{I}(S_{I}(foo)) and I+E(M(T(d))∈IOC. Because I satisfies T(V), S_{I}(foo))∈IOC, thus <S_{I}(foo),I+E(M(T(d)))> ∈ EXT_{I}(S_{I}(owl:sameClassAs)). Therefore I satisfies T(D).
If I satisfies T(D) then I satisfies T(intersectionOf(d_{1} … d_{n})). Thus there is some E as above such that <S_{I}(foo),I+E(M(T(d)))> ∈ EXT_{I}(S_{I}(owl:sameClassAs)). Thus EC(d) = CEXT_{I}(I+E(M(T(d)))) = CEXT_{I}(S_{I}(foo)) = EC(foo). Therefore I' satisfies D.
Let d=intersectionOf(d_{1} … d_{n}). As d is a description over V', thus I satisfies T(d) and for any E mapping the blank nodes of T(d) such that I+E satisfies T(d), CEXT_{I}(I+E(M(T(d)))) = EC(d). Thus for some E mapping the blank nodes of T(d) such that I+E satisfies T(d), CEXT_{I}(I+E(M(T(d)))) = EC(d) and I+E(M(T(d))∈IOC.
If I' satisfies D then EC(foo) ⊆ EC(d) From above, there is some E such that CEXT_{I}(I+E(M(T(d)))) = EC(d) ⊇ EC(foo) = CEXT_{I}(S_{I}(foo)) and I+E(M(T(d))∈IOC. Because I satisfies T(V), S_{I}(foo))∈IOC, thus <S_{I}(foo),I+E(M(T(d)))> ∈ EXT_{I}(S_{I}(rdfs:subClassOf)). Therefore I satisfies T(D).
If I satisfies T(D) then I satisfies T(intersectionOf(d_{1} … d_{n})). Thus there is some E as above such that <S_{I}(foo),I+E(M(T(d)))> ∈ EXT_{I}(S_{I}(rdfs:subClassOf)). Thus EC(d) = CEXT_{I}(I+E(M(T(d)))) ⊇ CEXT_{I}(S_{I}(foo)) = EC(foo). Therefore I' satisfies D.
Let d=oneOf(i_{1} … i_{n}). As d is a description over V' so I satisfies T(d) and for some E mapping the blank nodes of T(d) such that I+E satisfies T(d), CEXT_{I}(I+E(M(T(d)))) = EC(d).
If I' satisfies D then EC(foo) = EC(d). From above, there is some E such that CEXT_{I}(I+E(M(T(d)))) = EC(d) = EC(foo) = CEXT_{I}(S_{I}(foo)) and I+E(M(T(d))∈IOC. Because I satisfies T(V), S_{I}(foo))∈IOC, thus <S_{I}(foo),I+E(M(T(d)))> ∈ EXT_{I}(S_{I}(owl:sameClassAs)). Therefore I satisfies T(D).
If I satisfies T(D) then I satisfies T(intersectionOf(d_{1} … d_{n})). Thus there is some E as above such that <S_{I}(foo),I+E(M(T(d)))> ∈ EXT_{I}(S_{I}(owl:sameClassAs)). Thus EC(d) = CEXT_{I}(I+E(M(T(d)))) = CEXT_{I}(S_{I}(foo)) = EC(foo). Therefore I' satisfies D.
As d_{i} is a description over V' therefore I satisfies T(d_{i}) and for any E mapping the blank nodes of T(d_{i}) such that I+E satisfies T(d_{i}), CEXT_{I}(I+E(M(T(d_{i})))) = EC(d_{i}).
If I satisfies T(D) then for each 1≤i≤n there is some E_{i} such that I satisfies <I+E_{i}(M(T(d_{i}))),I+E_{j}(M(T(d_{j})))> ∈ EXT_{I}(S_{I}(owl:disjointWith)) for each 1≤i<j≤n. Thus EC(d_{i})∩EC(d_{j}) = {}, for i≠j. Therefore I' satisfies D.
If I' satisfies D then EC(d_{i})∪EC(d_{j}) = {} for i≠j. For any E_{i} and E_{j} as above <I+E_{i}+E_{j}(M(T(d_{i}))),I+E_{i}+E_{j}(M(T(d_{j})))< ∈ EXT_{I}(S_{I}(owl:disjointWith)), for i≠j. As at least one E_{i} exists for each i, and the blank nodes of the T(d_{j}) are all disjoint, I+E_{1}+…+E_{n} satisfies T(DisjointClasses(d_{1} … d_{n})). Therefore I satisfies T(D).
As d_{i} for 1≤i≤m is a description over V' therefore I satisfies T(d_{i}) and for any E mapping the blank nodes of T(d_{i}) such that I+E satisfies T(d_{i}), CEXT_{I}(I+E(M(T(d_{i})))) = EC(d_{i}). Similarly for r_{i} for 1≤i≤l.
If I' satisfies D, then, as p∈VOP, I satisfies S_{I}(p)∈IOOP. Then, as I is an OWL/DL interpretation, I satisfies <S_{I}(p),S_{I}(owl:Thing)>∈EXT_{I}(S_{I}(rdfs:domain)) and <S_{I}(p),S_{I}(owl:Thing)>∈EXT_{I}(S_{I}(rdfs:range)). Also, ER(p)⊆ER(s_{i}) for 1≤i≤n, so EXT_{I}(S_{I}(p))=ER(p) ⊆ ER(s_{i})=EXT_{I}(S_{I}(s_{i})) and I satisfies <S_{I}(p),S_{I}(s_{i})>∈EXT_{I}(S_{I}(rdfs:subPropertyOf)). Next, ER(p)⊆EC(d_{i})×R for 1≤i≤m, so <z,w>∈ER(p) → z∈EC(d_{i}) and for any E such that I+E satisfies T(d_{i}), <z,w>∈EXT_{I}(p) → z∈CEXT_{I}(I+E(M(T(d_{i})))) and thus <S_{I}(p),I+E(M(T(d_{i})))>∈EXT_{I}(S_{I}(rdfs:domain)). Similarly for r_{i}) for 1≤i≤l.
If I' satisfies D and inverse(i) is in D, then ER(p) and ER(i) are converses. Thus <u,v>∈ER(p) iff <v,u>∈ER(i) so <u,v>∈EXT_{I}(p) iff <v,u>∈EXT_{I}(i) and I satisfies <S_{I}(p),S_{I}(i)>∈EXT_{I}(S_{I}(owl:inverseOf)). If I' satisfies D and Symmetric is in D, then ER(p) is symmetric. Thus if <x,y>∈ ER(p) then <y,x>∈ER(p) so if <x,y> ∈ EXT_{I}(p) then <y, x>∈EXT_{I}(p). and thus I satisfies p∈CEXT_{I}(S_{I}(owl:Symmetric)). Similarly for Functional, InverseFunctional, and Transitive. Thus if I' satisfies D then I satisfies T(D).
If I satisfies T(D) then, for 1≤i≤n, <S_{I}(p),S_{I}(s_{i})>∈EXT_{I}(S_{I}(rdfs:subPropertyOf)). so ER(p)=EXT_{I}(S_{I}(p)) ⊆ EXT_{I}(S_{I}(s_{i}))=ER(s_{i}). Also, for 1≤i≤m, for some E such that I+E satisfies T(d_{i}), <S_{I}(p),I+E(M(T(d_{i})))>∈EXT_{I}(S_{I}(rdfs:domain)) so <z,w>∈EXT_{I}(p) → z∈CEXT_{I}(I+E(M(T(d_{i})))). Thus <z,w>∈ER(p) → z∈EC(d_{i}) and ER(p)⊆EC(d_{i})×R. Similarly for r_{i}) for 1≤i≤l.
If I satisfies T(D) and inverse(i) is in D, then I satisfies <S_{I}(p),S_{I}(i)>∈EXT_{I}(S_{I}(owl:inverseOf)). Thus <u,v>∈EXT_{I}(p) iff <v,u>∈EXT_{I}(i) so <u,v>∈ER(p) iff <v,u>∈ER(i) and ER(p) and ER(i) are converses. If I satisfies D and Symmetric is in D, then I satisfies p∈CEXT_{I}(S_{I}(owl:Symmetric)) so if <x,y> ∈ EXT_{I}(p) then <y, x>∈EXT_{I}(p). Thus if <x,y>∈ ER(p) then <y,x>∈ER(p) and ER(p) is symmetric. Similarly for Functional, InverseFunctional, and Transitive. Thus if I satisfies T(D) then I' satisfies D.
As p_{i}∈VOP and I satisfies T(V'), S_{I}(p_{i})∈IOP. If I satisfies T(D) then <S_{I}(p_{i}),S_{I}(p_{j})> ∈ EXT_{I}(S_{I}(owl:samePropertyAs)), for each 1≤i<j≤n. Therefore EXT_{I}(p_{i}) = EXT_{I}(p_{j}), for each 1≤i<j≤n; CR(p_{i}) = CR(p_{j}), for each 1≤i<j≤n; and I' satisfies D.
If I' satisfies D then CR(p_{i}) = CR(p_{j}), for each 1≤i<j≤n. Therefore EXT_{I}(p_{i}) = EXT_{I}(p_{j}), for each 1≤i<j≤n. From the OWL/DL definition of owl:samePropertyAs, <S_{I}(p_{i}),S_{I}(p_{j})> ∈ EXT_{I}(S_{I}(owl:samePropertyAs)), for each 1≤i<j≤n. Thus I satisfies T(D).
If I satisfies T(D) then there is some E that maps each blank node in T(D) such that I+E satisfies T(D). A simple examination of T(D) shows that the mappings of E plus the mappings for the individual IDs in D, which are all in IOT, show that I' satisfies D.
If I' satisfies D then for each Individual construct in D there must be some element of R that makes the class memberships and relationships true in D. The ntriples in T(D) then fall into three categories. 1/ Type relationships to owl:Thing, which are true in I because the elements above belong to R. 2/ Type relationships to OWL descriptions, which are true in I because they are true in I', from Lemma 1. 3/ OWL property relationships, which are true in I' because they are true in I. Thus I satisfies T(D).
Let V' = <VI, VC, VD, VOP, VDP> be a separated OWL vocabulary. Let V = VI ∪ VC ∪ VD ∪ VOP ∪ VDP ∪ VRDFS ∪ VOWL. Then for every OWL/DL interpretation I = < R_{I}, EXT_{I}, S_{I} > over V that satisfies T(V') there is an abstract OWL interpretation I' over V' such that for any OWL abstract KB K over V, I' abstract OWL satisfies K iff I OWL/DL satisfies T(K).
Proof
Let CEXT_{I} be defined as usual from I. The required abstract OWL interpretation will be I' = < CEXT_{I}(S_{I}(owl:Thing)), S, EC, ER > where S(n) = S_{I}(n) for n∈VI, EC(n) = CEXT_{I}(S_{I}(n)) for n∈VC∪VD, and ER(n) = EXT_{I}(S_{I}(n)) for n∈VOP∪VDP.
Satisfying an abstract KB is just satisfying its directives and satisfying the translation of an abstract KB is just satisfying all the ntriples so I OWL/DL satisfies T(K) iff I' abstract OWL satisfies K.
Let V' = <VI, VC, VD, VOP, VDP> be a separated OWL vocabulary. Let V = VI ∪ VC ∪ VD ∪ VOP ∪ VDP ∪ VRDFS ∪ VOWL. Then for every Abstract OWL interpretation I' = < U, S, EC, ER > over V' there is an OWL/DL interpretation I over V that satisfies T(V') such that for any abstract OWL KB K over V', I OWL/DL satisfies T(K) iff I' abstract OWL satisfies K.
Proof
Let V' be a separated OWL vocabulary. Let K,Q be abstract OWL knowledge bases with separated names over V'. Then K OWL entails Q iff T(K),T(V') OWL/DL entails T(Q).
Proof
Suppose K OWL entails Q. Let I be an OWL/DL interpretation that satisfies T(K),T(V'). Then from Lemma 3, there is some abstract OWL interpretation I' such that for any abstract OWL knowledge base X over V', I satisfies T(X) iff I' satisfies X. Thus I' satisfies K. Because K OWL entails Q, I' satisfies Q, so I satisfies T(Q). Thus T(K),T(V') OWL/DL entails T(Q).
Suppose T(K),T(V') OWL/DL entails T(Q). Let I' be an abstract OWL interpretation that satisfies K. Then from Lemma 4, there is some OWL/DL interpretation I that satisfies T(V') such that for any abstract OWL knowledge base X over V', I satisfies T(X) iff I' satisfies X. Thus I satisfies T(K). Because T(K),T(V') OWL/DL entails T(Q), I satisfies T(Q), so I' satisfies Q. Thus K abstract OWL entails Q.
This section contains a poof sketch concerning the relationship between OWL/DL and OWL/Full. This proof has not been fully worked out. Significant effort may be required to finish the proof and some details of the relationship may have to change.
Let K be a collection of ntriples. An OWL interpretation of of K is an OWL interpretation (from Section 5.2) that is an RDFS interpretation of K.
Lemma: Let K be an OWL KB in the abstract syntax with separated vocabulary. Then for every OWL interpretation of T(K) there is an OWL/DL interpretation (as in Section 5.3) of T(K), and vice versa.
Proof sketch: As all OWL/DL interpretations are OWL interpretations, the reverse direction is obvious.
Let I = < R_{I}, EXT_{I}, S_{I} > be an OWL interpretation of T(K). Let I' = < R_{I'}, EXT_{I'}, S_{I'} > be an OWL interpretation of T(K). Let R_{I'} = CEXT_{I}(S_{I}(owl:Thing)) + CEXT_{I}(S_{I}(owl:ObjectProperty)) + CEXT_{I}(S_{I}(owl:IndividualProperty)) + CEXT_{I}(S_{I}(owl:Class)) + CEXT_{I}(S_{I}(rdf:List)) + R_{I}, where + is disjoint union. Define EXT_{I'} so as to separate the various roles of the copies. Define S_{I'} so as to map vocabulary into the appropriate copy. This works because K has a separated vocabulary, so S_{I} can be split according the the roles, and there are no inappropriate relationships in EXT_{I}. In essence the first component of R_{I'} is OWL individuals, the second component of R_{I'} is OWL datatype properties, the third component of R_{I'} is OWL object properties, the fourth component of R_{I'} is OWL classes, the fifth component of R_{I'} is RDF lists, and the sixth component of R_{I'} is everything else.
Theorem: Let K,C be collections of ntriples such that each of K, C, and K∪C is the translation of some OWL KB in the abstract syntax with separated vocabulary. Then K OWL/Full entails C if K OWL/DL entails C.
Proof: From the above lemma and because all OWL/Full interpretations are OWL interpretations.
Comment: The only if direction cannot be proved without showing that OWL/Full has no semantic oddities, which has not yet been done.
This appendix gives examples of the concepts developed in the rest of the document.
The transformation rules in Section 4 transform
DatatypeProperty(ex:name) ObjectProperty(ex:author) Individual(type(ex:Book) (ex:author (Individual (ex:name xsd:string"Fred"))))
to
[ex:name] [rdf:type] [owl:DatatypeProperty] . [ex:name] [rdfs:domain] [owl:Thing] . [ex:name] [rdfs:range] [rdfs:Literal] . [ex:author] [rdf:type] [owl:ObjectProperty] . [ex:author] [rdfs:domain] [owl:Thing] . [ex:author] [rdfs:range] [owl:Thing] . [ex:book] [rdf:type] [owl:Class] . [ex:book] [rdfs:subClassOf] [owl:Thing] . _:x [rdf:type] [owl:Thing] . _:x [rdf:type] [ex:Book] . _:x [ex:author] _:x1 . _:x1 [rdf:type] [owl:Thing] . _:x1 [ex:name] xsd:string"Fred" .
and
ObjectProperty(ex:enrolledIn) Class(ex:Student complete ex:Person restriction(ex:enrolledIn allValuesFrom(ex:School) minCardinality(1)))
to
[ex:enrolledIn] [rdf:type] [owl:ObjectProperty] . [ex:enrolledIn] [rdfs:domain] [owl:Thing] . [ex:enrolledIn] [rdfs:range] [owl:Thing] . [ex:Person] [rdf:type] [owl:Class] . [ex:Person] [rdf:subClassOf] [owl:Thing] . [ex:School] [rdf:type] [owl:Class] . [ex:School] [rdf:subClassOf] [owl:Thing] . [ex:Student] [rdf:type] [owl:Class] . [ex:Student] [rdf:subClassOf] [owl:Thing] . [ex:Student] [owl:sameClassAs] _:x . _:x [owl:intersectionOf] _:l1 . _:l1 [rdf:type] [rdf:List] . _:l1 [rdf:first] [ex:Person] . _:l1 [rdf:rest] [rdf:nil] . _:l2 [rdf:type] [rdf:List] . _:l2 [rdf:first] _:lr . _:l2 [rdf:rest] [rdf:nil] . _:lr [owl:intersectionOf] _:lr1 . _:lr1 [rdf:type] [rdf:List] . _:lr1 [rdf:first] _:r1 . _:lr1 [rdf:rest] _:lr2 . _:lr2 [rdf:type] [rdf:List] . _:lr2 [rdf:first] _:r2 . _:lr2 [rdf:rest] [rdf:nil] . _:r1 [rdf:type] [owl:Restriction] . _:r1 [owl:onProperty] [ex:enrolledIn] . _:r1 [owl:allValuesFrom] [ex:School] . _:r2 [rdf:type] [owl:Restriction] . _:r2 [owl:onProperty] [ex:enrolledIn] . _:r2 [owl:minCardinality] xsd:decimal"1" .
OWL/DL supports the entailments that one would expect, as long as the vocabulary can be shown to belong to the appropriate piece of the domain of discourse. For example,
John friend Susan .
does not OWL/DL entail
John rdf:type owl:Thing .
Susan rdf:type owl:Thing .
friend rdf:type owl:ObjectProperty .
and so all this would need to be added explicitly as an antecedent in order to draw the conclusion
John rdf:type _:x .
_:x owl:onProperty friend .
_:x owl:minCardinality 1 .
However, once these extra conditions are added, all natural entailments follow, except for those that involve descriptions with loops. For example,
John rdf:type owl:Thing .
friend rdf:type owl:ObjectProperty .
John rdf:type _:x .
_:x owl:onProperty friend .
_:x owl:maxCardinality 0 .
does not entail
John rdf:type _:x .
_:y owl:onProperty friend .
_:y owl:allValuesFrom _:y .
because there are no comprehension principles for such looping descriptions. It is precisely the lack of such comprehension principles that prevent the formation of paradoxes in OWL/DL while still retaining natural entailments.
In OWL/DL one can repair missing localizations in any separatedsyntax KB by adding a particular set of localizing assertions consisting of all triples of the form
<individual> rdf:type owl:Thing .
<class> rdf:type owl:Class .
<oproperty> rdf:type owl:ObjectProperty .
<dtproperty> rdf:type owl:DataTypeProperty .
Call the result of adding all such assertions to a OWL/DL KB the localization of the KB.
OWL/Full supports the entailments that one would expect, and there is no need to provide typing information for the vocabulary. For example,
John friend Susan .
does OWL/Full entail
John rdf:type _:x .
_:x owl:onProperty friend .
_:x owl:minCardinality 1 .