W3C

OWL Web Ontology Language
Semantics and Abstract Syntax

W3C ProposedRecommendation 15 December 200310 February 2004

PRE-PUBLICATION DRAFT. This document is being prepared for possible publication by the W3C, but it may change, be delayed, or never be published. The "Version" URIs and "Status of this Document" section may reflect its planned location and status, not present reality.

This version:
http://www.w3.org/TR/2003/PR-owl-semantics-20031215/http://www.w3.org/2001/sw/WebOnt/TR/STAGE-owl-semantics/
Latest version:
http://www.w3.org/TR/owl-semantics/
Previous version:
http://www.w3.org/TR/2003/CR-owl-semantics-20030818/
Editors:
Peter F. Patel-Schneider, Bell Labs Research, Lucent Technologies
Patrick Hayes, IHMC, University of West Florida
Ian Horrocks, Department of Computer Science, University of Manchester

Please refer to the errata for this document, which may include some normative corrections.

The normative form of this document is a compound HTML document.

See also translations.


Abstract

This description of OWL, the Web Ontology Language being designed by the W3C Web Ontology Working Group, contains a high-level abstract syntax for both OWL DL and OWL Lite, sublanguages of OWL. A model-theoretic semantics is given to provide a formal meaning for OWL ontologies written in this abstract syntax. A model-theoretic semantics in the form of an extension to the RDF semantics is also given to provide a formal meaning for OWL ontologies as RDF graphs (OWL Full). A mapping from the abstract syntax to RDF graphs 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.

Status of this document

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

Publication as a Proposed Recommendation 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. This draft isone of six parts of the ProposedW3C Recommendation (PR)for OWL, the Web Ontology Language. It has been developed by the Web Ontology Working Group as part of the W3C Semantic Web Activity (Activity Statement, Group Charter) for publication on 15 December 2003.10 February 2004.

The design of OWL expressed in earlier versions of these documents has been widely reviewed and satisfies the Working Group's technical requirements. The Working Group has addressed all comments received, making changes as necessary. During Candidate Recommendation, many implementations were reported, covering among them all features of the language.Changes to this document since the CandidateProposed Recommendation version are detailed in the change log.

This document has been reviewed by W3C Advisory Committee Representatives are invited to submit their formal review perMembers and other interested parties, and has been endorsed by the instructionsDirector as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Call for Review. The publicRecommendation is invitedto send commentsdraw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

Comments are welcome at public-webont-comments@w3.org (archive) and to participate ingeneral discussion of related technology is welcome at www-rdf-logic@w3.org (archive).

The review period extends until 12 January 2004 .A list of implementations is available.

The W3C maintains a list of any patent disclosures related to this work.


Table of contents


1. Introduction (Informative)

This document is one part of the specification of OWL, the Web Ontology Language. The OWL Overview [OWL Overview] describes each of the different documents in the specification and how they fit together.

This document contains several interrelated normative specifications of the several styles of OWL, the Web Ontology Language being produced by the W3C Web Ontology Working Group (WebOnt). First, Section 2 contains a high-level, abstract syntax for both OWL Lite, a subset of OWL, and OWL DL, a fuller style of using OWL but one that still places some limitations on how OWL ontologies are constructed. Eliminating these limitations results in the full OWL language, called OWL Full, which has the same syntax as RDF. The normative exchange syntax for OWL is RDF/XML [RDF Syntax]; the OWL Reference document [OWL Reference] shows how the RDF syntax is used in OWL. A mapping from the OWL abstract syntax to RDF graphs [RDF Concepts] 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 model-theoretic semantics for OWL ontologies written in the abstract syntax. The other, defined in Section 5, is a vocabulary extension of the RDF semantics [RDF MTSemantics] that provides semantics for OWL ontologies in the form of RDF graphs. Two versions of this second semantics are provided, one that corresponds more closely to the direct semantics (and is thus a semantics for OWL DL) and one that can be used in cases where classes need to be treated as individuals or other situations that cannot be handled in the abstract syntax (and is thus a semantics for OWL Full). 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 direct and RDFS-compatible 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. Appendix A also contains the sketch of a proof that the entailments in the RDFS-compatible semantics for OWL Full include all the entailments in the RDFS-compatible semantics for OWL DL. Finally a few examples of the various concepts defined in the document are presented in Appendix B.

This document is designed to be read by those interested in the technical details of OWL. It is not particularly intended for the casual reader, who should probably first read the OWL Guide [OWL Guide]. Developers of parsers and other syntactic tools for OWL will be particularly interested in Sections 2 and 4. Developers of reasoners and other semantic tools for OWL will be particularly interested in Sections 3 and 5.


2. Abstract Syntax (Normative)

The syntax for OWL in this section abstracts from exchange syntax for OWL and thus facilitates access to and evaluation of the language. This particular syntax has a frame-like 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 when writing OWL as RDF graphs [RDF Concepts]). 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.

The abstract syntax is specified here by means of a version of Extended BNF, very similar to the EBNF notation used for XML [XML]. Terminals are quoted; non-terminals are bold and not quoted. Alternatives are either separated by vertical bars (|) or are given in different productions. Components that can occur at most once are enclosed in square brackets ([…]); components that can occur any number of times (including zero) are enclosed in braces ({…}). Whitespace is ignored in the productions here.

Names in the abstract syntax are RDF URI references, [RDF Concepts]. Often these names will be abbreviated into qualified names, using one of the following namespace names:

Namespace nameNamespace
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfshttp://www.w3.org/2000/01/rdf-schema#
xsdhttp://www.w3.org/2001/XMLSchema#
owlhttp://www.w3.org/2002/07/owl#

The meaning of each construct in the abstract syntax is informally described when it is introduced. The formal meaning of these constructs is given in Section 3 via a model-theoretic semantics.

While it is widely appreciated that all of the features in expressive languages such as OWL 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 simpler target for implementation, a smaller language has been defined, called OWL Lite [OWL Overview]. This smaller language was designed to provide functionality that is important in order to support Web applications, but that is missing in RDF Schema [RDF Schema]. (Note, however, that both OWL DL and OWL Lite do not provide all of the feature of RDF Schema.) The abstract syntax is expressed both for this smaller language, called the OWL Lite abstract syntax here, and also for a fuller style of OWL, called the OWL DL abstract syntax here.

The abstract syntax here is less general than the exchange syntax for OWL. In particular, it does not permit the construction of self-referential syntactic constructs. It is also intended for use in cases where classes, properties, and individuals form disjoint collections. These are roughly the limitations required to make reasoning in OWL be decidable, and thus this abstract syntax should be thought of a syntax for OWL DL.

NOTE: OWL Lite and OWL DL closely correspond to the description logics known as SHIF(D) and SHION(D), with some limitation on how datatypes are treated. The abstract syntax for OWL Lite doesn't contain many of the common explicit constructors associated with SHIF(D), but the expressivity remains.

2.1. Ontologies

An OWL ontology in the abstract syntax contains a sequence of annotations, axioms, and facts. OWL ontologies can have a name. Annotations on OWL ontologies can be used to record authorship and other information associated with an ontology, including imports references to other ontologies. The main content of an OWL ontology is carried in its axioms and facts, which provide information about classes, properties, and individuals in the ontology.

ontology ::= 'Ontology(' [ ontologyID ] { directive } ')'
directive ::= 'Annotation(' ontologyPropertyID ontologyID ')'
	 | 'Annotation(' annotationPropertyID URIreference ')'
         | 'Annotation(' annotationPropertyID dataLiteral ')'
         | 'Annotation(' annotationPropertyID individual ')'
         | axiom
         | fact

Names of ontologies are used in the abstract syntax to carry the meaning associated with publishing an ontology on the Web. Names of ontologies are used in the abstract syntax to carry the meaning associated with publishing an ontology on the Web. It is thus intended that the name of an ontology in the abstract syntax would be the URI where it could be found, although this is not part of the formal meaning of OWL. Imports annotations, in effect, are directives to retrieve a Web document and treat it as an OWL ontology. However, most aspects of the Web, including missing, unavailable, and time-varying documents, reside outside the OWL specification; all that is carried here is that a URI can be ``dereferenced'' into an OWL ontology. In several places in this document, therefore, idealizations of this operational meaning for imports are used.

Ontologies incorporate information about classes, properties, and individuals, each of which can have an identifier which is a URI reference. Some of these identifiers need to be given axioms, as detailed in Section 2.3.

datatypeID ::= URIreference
classID ::= URIreference
individualID ::= URIreference
ontologyID ::= URIreference
datavaluedPropertyID ::= URIreference
individualvaluedPropertyID ::= URIreference
annotationPropertyID ::= URIreference
ontologyPropertyID ::= URIreference

A URI reference cannot be both a datatypeID and a classID in an ontology. A URI reference also cannot be more than one of an datavaluedPropertyID, an individualvaluedPropertyID, an annotationPropertyID, or an ontologyPropertyID in an ontology. However, a URI reference can be the identifier of a class or datatype as well as the identifier of a property as well as the identifier of an individual, although the ontology cannot then be translated into an OWL DL RDF graph.

In OWL a datatype denotes the set of 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 four disjoint groups, data-valued properties, individual-valued properties, annotation properties, and ontology properties. Data-valued properties relate individuals to data values. Individual-valued properties relate individuals to other individuals. Annotation properties are used to place annotations on individuals, class names, property names, and ontology names. Ontology properties relate ontologies to other ontologies, in particular being used for importing information from other ontologies. Individual identifiers are used to refer to resources, and data literals are used to refer to data values.

There are two built-in classes in OWL, they both use URI references in the OWL namespace, i.e., names starting with http://www.w3.org/2002/07/owl#, for which the namespace name owl is used here. (Throughout this document qualified names will be used as abbreviations for URI references.) The class with identifier owl:Thing is the class of all individuals. The class with identifier owl:Nothing is the empty class. Both classes are part of OWL Lite.

The following XML Schema datatypes [XML Schema Datatypes] can be used in OWL as built-in datatypes by means of the XML Schema canonical URI reference for the datatype, http://www.w3.org/2001/XMLSchema#name, where name is the local name of the datatype: xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary, xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name, xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte and xsd:positiveInteger. The other built-in XML Schema datatypes are problematic for OWL, as discussed in Section 5.1 of RDF Semantics [RDF MTSemantics]. The built-in RDF datatype, rdf:XMLLiteral, is also an OWL built-in datatype. Because there is no standard way to go from a URI reference to an XML Schema datatype in an XML Schema, there is no standard way to use user-defined XML Schema datatypes in OWL.

There are several built-in annotation properties in OWL, namely owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, and rdfs:isDefinedBy. In keeping with their definition in RDF, rdfs:label and rdfs:comment can only be used with data literals.

There are also several built-in ontology properties; they are owl:imports, owl:priorVersion, owl:backwardCompatibleWith, and owl:incompatibleWith. Ontology annotations that use owl:imports have the extra effect of importing the target ontology.

Many OWL constructs use annotations, which, just like annotation directives, are used to record information associated with some portion of the construct.

annotation ::= 'annotation(' annotationPropertyID URIreference ')'
            | 'annotation(' annotationPropertyID dataLiteral ')'
            | 'annotation(' annotationPropertyID individual ')'

2.2. Facts

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 somewhat mirror RDF/XML syntax [RDF Syntax] without the use of rdf:nodeID.

fact ::= individual 
individual ::= 'Individual(' [ individualID ] { annotation } { 'type(' type ')' } { value } ')'
value ::= 'value(' individualvaluedPropertyID individualID ')'
        | 'value(' individualvaluedPropertyID  individual ')'
        | 'value(' datavaluedPropertyID  dataLiteral ')'

Facts are the same in the OWL Lite and OWL DL abstract syntaxes, except for what can be a type. In OWL Lite, types can be class IDs or OWL Lite restrictions, see Section 2.3.1.2

type ::= classID
       | restriction

In the OWL DL abstract syntax types can be general descriptions, which include class IDs and OWL Lite restrictions as well as other constructs

type ::= description

Data literals in the abstract syntax are either plain literals or typed literals. Plain literals consist of a Unicode string in Normal Form C and an optional language tag, as in RDF plain literals [RDF Concepts]. Typed literals consist of a lexical representation and a URI reference, as in RDF typed literals [RDF Concepts].

dataLiteral ::= typedLiteral | plainLiteral
typedLiteral ::= lexicalForm^^URIreference
plainLiteral ::= lexicalForm | lexicalForm@languageTag
lexicalForm ::= as in RDF, a unicode string in normal form C
languageTag ::= as in RDF, an XML language tag

The second kind of fact is used to make individual identifiers be the same or pairwise distinct.

fact ::= 'SameIndividual(' individualID individualID {individualID} ')'
      | 'DifferentIndividuals(' individualID individualID {individualID} ')'

2.3. Axioms

The biggest differences between the OWL Lite and OWL DL abstract syntaxes 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, in Section 2.3.1. The OWL DL axioms are given in Section 2.3.2. OWL DL axioms include OWL Lite axioms as special cases.

Axioms are used to associate class and property identifiers with either partial or complete specifications of their characteristics, and to give other information about classes and properties. Axioms used to be called definitions, but they are not all definitions in the common sense of the term and thus a more neutral 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 more-general 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 more-general classes and restrictions. In the OWL DL abstract syntax a class axiom contains a collection of descriptions, which can be more-general classes, restrictions, sets of individuals, and boolean combinations of descriptions. Classes can also be specified by enumeration or be made equivalent or disjoint.

Properties can be equivalent to or sub-properties of others; can be made functional, inverse functional, symmetric, or transitive; and can be given global domains and ranges. However, most information concerning properties is more naturally expressed in restrictions, which allow local range and cardinality information to be specified.

URI references used as class IDs or datatype IDs have to be differentiated, and so need an axiom, except for the built-in OWL classes and datatypes and rdfs:Literal. There can be more than one axiom for a class or datatype. Properties used in an abstract syntax ontology have to be categorized as either data-valued or individual-valued or annotation properties. Properties thus also need an axiom for this purpose, at least. If an ontology imports another ontology, the axioms in the imported ontology (and any ontologies it imports, and so on) can be used for these purposes.

2.3.1. OWL Lite Axioms

2.3.1.1. OWL Lite Class Axioms

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. It is also possible to indicate that the use of a class is deprecated.

axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { super } ')'
modality ::= 'complete' | 'partial'
super ::= classID | restriction

In OWL Lite it is possible to state that two or more classes are equivalent.

axiom ::= 'EquivalentClasses(' classID classID { classID } ')'

Datatype axioms are simpler, only serving to say that a datatype ID is the ID of a datatype and to give annotations for the datatype.

axiom ::= 'Datatype(' datatypeID ['Deprecated']  { annotation } )'
2.3.1.2. OWL Lite Restrictions

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

See Section 2.3.1.3 for a limitation on which properties can have cardinality parts in restrictions.

restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent ')'
            | 'restriction(' individualvaluedPropertyID individualRestrictionComponent ')'
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
            | 'someValuesFrom(' dataRange ')'
            | cardinality
individualRestrictionComponent ::= 'allValuesFrom(' classID ')'
            | 'someValuesFrom(' classID ')'
            | cardinality 
cardinality ::= 'minCardinality(0)' | 'minCardinality(1)'
            | 'maxCardinality(0)' | 'maxCardinality(1)'
            | 'cardinality(0)'    | 'cardinality(1)'
2.3.1.3. OWL Lite Property Axioms

Properties are also specified using a frame-like syntax. Data-valued properties relate individuals to data values, like integers. Individual-valued properties relate individuals to other individuals. These two kinds of properties can be given super-properties, allowing the construction of a property hierarchy. It does not make sense to have an individual-valued property be a super-property of a data-valued property, or vice versa. Data-valued and individual-valued 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 predicate, just as in RDFS. In OWL Lite the domains of properties are classes. There can be 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 statements that have the property as predicate. Again, there can be 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 individual-valued properties are classes; ranges for data-valued properties are datatypes.

Data-valued 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. Individual-valued properties can be specified to be the inverse of another property. Individual-valued properties can also be specified to be symmetric as well as partial functional, partial inverse-functional, or transitive.

To preserve decidability of reasoning in OWL Lite, not all properties can have cardinality restrictions placed on them or be specified as functional or inverse-functional. An individual-valued property is complex if 1/ it is specified as being functional or inverse-functional, 2/ there is some cardinality restriction that uses it, 3/ it has an inverse that is complex, or 4/ it has a super-property that is complex. Complex properties cannot be specified as being transitive.

Annotation and ontology properties are much simpler than data-valued and individual-valued properties. The only information in axioms for them is annotations.

axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation } 
              { 'super(' datavaluedPropertyID ')' } ['Functional'] 
              { 'domain(' classID' ')' } { 'range(' dataRange ')' } ')'
       | 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation } 
              { 'super(' individualvaluedPropertyID ')' }
              [ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ] 
              [ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ]
              { 'domain(' classID ')' } { 'range(' classID ')' } ')'
       | 'AnnotationProperty(' annotationPropertyID { annotation } ')'
       | 'OntologyProperty(' ontologyPropertyID { annotation } ')'
dataRange ::= datatypeID | 'rdfs:Literal'

The following axioms make several properties be equivalent, or make one property be a sub-property of another.

axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID  { datavaluedPropertyID } ')'
        | 'SubPropertyOf(' datavaluedPropertyID  datavaluedPropertyID ')'
        | 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID  { individualvaluedPropertyID } ')'
        | 'SubPropertyOf(' individualvaluedPropertyID  individualvaluedPropertyID ')'

2.3.2. OWL DL Axioms

2.3.2.1. OWL DL Class Axioms

The OWL DL abstract syntax has more-general versions of the OWL Lite class axioms where superclasses, more-general restrictions, and boolean combinations of these are allowed. Together, these constructs are called descriptions.

axiom ::= 'Class(' classID  ['Deprecated'] modality { annotation } { description } ')'
modality ::= 'complete' | 'partial'

In the OWL DL abstract syntax it is also possible to make a class exactly consist of a certain set of individuals, as follows.

axiom ::= 'EnumeratedClass(' classID ['Deprecated'] { annotation } { individualID } ')'

Finally, in the OWL DL abstract syntax it is possible to require that a collection of descriptions be pairwise disjoint, or have the same instances, or that one description is a subclass of another. Note that the last two of these axioms generalize, except for lack of annotation, the first kind of class axiom just above.

axiom ::= 'DisjointClasses(' description description { description } ')'
        | 'EquivalentClasses(' description { description } ')'
        | 'SubClassOf(' description description ')'

In OWL DL it is possible to have only one description in an EquivalentClasses construct. This allows ontologies to include descriptions that are not connected to anything, which is not semantically useful, but makes allowances for less-than-optimal editing of ontologies.

Datatype axioms are the same as in OWL Lite.

axiom ::= 'Datatype(' datatypeID ['Deprecated']  { annotation } )'
2.3.2.2. OWL DL Descriptions

Descriptions in the OWL DL abstract syntax include class identifiers and restrictions. Descriptions can also be boolean combinations of other descriptions, and sets of individuals.

description ::= classID
            | restriction
            | 'unionOf(' { description } ')'
            | 'intersectionOf(' { description } ')'
            | 'complementOf(' description ')'
            | 'oneOf(' { individualID } ')'
2.3.2.3. OWL DL Restrictions

Restrictions in the OWL DL 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 OWL DL abstract syntax, values can also be given for properties in classes. In addition, cardinalities are not restricted to only 0 and 1.

restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent { dataRestrictionComponent } ')'
            | 'restriction(' individualvaluedPropertyID individualRestrictionComponent { individualRestrictionComponent } ')'
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
            | 'someValuesFrom(' dataRange ')'
            | 'value(' dataLiteral ')'
            | cardinality
individualRestrictionComponent ::= 'allValuesFrom(' description ')'
            | 'someValuesFrom(' description ')'
            | 'value(' individualID ')'
            | cardinality 
cardinality ::= 'minCardinality(' non-negative-integer ')'
            | 'maxCardinality(' non-negative-integer ')'
            | 'cardinality(' non-negative-integer ')'

A data range, used as the range of a data-valued property and in other places in the OWL DL abstract syntax, is either a datatype or a set of data values.


dataRange ::= datatypeID | 'rdfs:Literal'
            | 'oneOf(' { dataLiteral } ')'

The OWL Lite limitations on which properties can have cardinality components in their restrictions are also present in OWL DL.

2.3.2.4. OWL DL Property Axioms

Property axioms in the OWL DL 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 ['Deprecated'] { annotation } 
                { 'super(' datavaluedPropertyID ')'} ['Functional']
                { 'domain(' description ')' } { 'range(' dataRange ')' } ')'
        | 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation } 
                { 'super(' individualvaluedPropertyID ')' }
                [ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ] 
                [ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ]
                { 'domain(' description ')' } { 'range(' description ')' } ')'
        | 'AnnotationProperty(' annotationPropertyID { annotation } ')'
        | 'OntologyProperty(' ontologyPropertyID { annotation } ')'

The limitations on which properties can be specified to be functional or inverse-functional are also present in OWL DL.

As in OWL Lite, the following axioms make several properties be equivalent, or make one property be a sub-property of another.

axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID  { datavaluedPropertyID } ')'
        | 'SubPropertyOf(' datavaluedPropertyID  datavaluedPropertyID ')'
        | 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID
                                  { individualvaluedPropertyID } ')'
        | 'SubPropertyOf(' individualvaluedPropertyID  individualvaluedPropertyID ')'

3. Direct Model-Theoretic Semantics (Normative)

This model-theoretic semantics for OWL goes directly from ontologies in the OWL DL abstract syntax, which includes the OWL Lite abstract syntax, to a standard model theory. It is simpler than the semantics in Section 5, which is a vocabulary extension of the RDFS semantics.

3.1. Vocabularies and Interpretations

The semantics here starts with the notion of a vocabulary. When considering an OWL ontology, the vocabulary must include all the URI references and literals in that ontology, as well as ontologies that are imported by the ontology, but can include other URI references and literals as well.

In this section VOP will be the URI references for the built-in OWL ontology properties.

Definition: An OWL vocabulary V consists of a set of literals VL and seven sets of URI references, VC, VD, VI, VDP, VIP, VAP, and VO. In any vocabulary VC and VD are disjoint and VDP, VIP, VAP, and VOP are pairwise disjoint. VC, the class names of a vocabulary, contains owl:Thing and owl:Nothing. VD, the datatype names of a vocabulary, contains the URI references for the built-in OWL datatypes and rdfs:Literal. VAP, the annotation property names of a vocabulary, contains owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, and rdfs:isDefinedBy. VIP, the individual-valued property names of a vocabulary, VDP, the data-valued property names of a vocabulary, and VI, the individual names of a vocabulary, VO, the ontology names of a vocabulary, do not have any required members.

Definition: As in RDF, a datatype d is characterized by a lexical space, L(d), which is a set of Unicode strings; a value space, V(d); and a total mapping L2V(d) from the lexical space to the value space.

Definition: A datatype map D is a partial mapping from URI references to datatypes that maps xsd:string and xsd:integer to the appropriate XML Schema datatypes.

A datatype map may contain datatypes for the other built-in OWL datatypes. It may also contain other datatypes, but there is no provision in the OWL syntax for conveying what these datatypes are.

Definition: Let D be a datatype map. An Abstract OWL interpretation with respect to D with vocabulary VL, VC, VD, VI, VDP, VIP, VAP, VO is a tuple of the form: I = <R, EC, ER, L, S, LV> where (with P being the power set operator)

EC provides meaning for URI references that are used as OWL classes and datatypes. ER provides meaning for URI references that are used as OWL properties. (The property rdf:type is added to the annotation properties so as to provide a meaning for deprecation, see below.)'' L provides meaning for typed literals. S provides meaning for URI references that are used to denote OWL individuals, and helps provide meaning for annotations. Note that there are no interpretations that can satisfy all the requirements placed on badly-formed literals, i.e., one whose lexical form is invalid for the datatype, such as 1.5^^xsd:integer.

S is extended to plain literals in VL by (essentially) mapping them onto themselves, i.e., S("l") = l for l a plain literal without a language tag and S("l"@t) = <l,t> for l a plain literal with a language tag. S is extended to typed literals by using L, S(l) = L(l) for l a typed literal.

3.2. Interpreting Embedded Constructs

EC is extended to the syntactic constructs of descriptions, data ranges, individuals, values, and annotations as in the EC Extension Table.

EC Extension Table
Abstract SyntaxInterpretation (value of EC)
complementOf(c) O - EC(c)
unionOf(c1 … cn) EC(c1) ∪ … ∪ EC(cn)
intersectionOf(c1 … cn) EC(c1) ∩ … ∩ EC(cn)
oneOf(i1 … in), for ij individual IDs {S(i1), …, S(in)}
oneOf(v1 … vn), for vj literals {S(v1), …, S(vn)}
restriction(p x1 … xn), for n > 1 EC(restriction(p x1)) ∩…∩EC(restriction(p xn))
restriction(p allValuesFrom(r)) {x ∈ O | <x,y> ∈ ER(p) implies y ∈ EC(r)}
restriction(p someValuesFrom(e)) {x ∈ O | ∃ <x,y> ∈ ER(p) ∧ y ∈ EC(e)}
restriction(p value(i)), for i an individual ID {x ∈ O | <x,S(i)> ∈ ER(p)}
restriction(p value(v)), for v a literal {x ∈ O | <x,S(v)> ∈ ER(p)}
restriction(p minCardinality(n)) {x ∈ O | card({y ∈ O∪LV : <x,y> ∈ ER(p)}) ≥ n}
restriction(p maxCardinality(n)) {x ∈ O | card({y ∈ O∪LV : <x,y> ∈ ER(p)}) ≤ n}
restriction(p cardinality(n)) {x ∈ O | card({y ∈ O∪LV : <x,y> ∈ ER(p)}) = n}
Individual(annotation(p1 o1)annotation(pk ok)
    type(c1)type(cm) pv1 … pvn)
EC(annotation(p1 o1)) ∩ … EC(annotation(pk ok)) ∩
EC(c1) ∩ … ∩ EC(cm) ∩ EC(pv1) ∩…∩ EC(pvn)
Individual(i annotation(p1 o1)annotation(pk ok)
    type(c1)type(cm) pv1 … pvn)
{S(i)} ∩ EC(annotation(p1 o1)) ∩ … EC(annotation(pk ok)) ∩
EC(c1) ∩ … ∩ EC(cm) ∩ EC(pv1) ∩…∩ EC(pvn)
value(p Individual()) {x ∈ O | ∃ y∈EC(Individual()) : <x,y> ∈ ER(p)}
value(p id) for id an individual ID {x ∈ O | <x,S(id)> ∈ ER(p) }
value(p v) for v a literal {x ∈ O | <x,S(v)> ∈ ER(p) }
annotation(p o) for o a URI reference {x ∈ R | <x,S(o)> ∈ ER(p) }
annotation(p Individual(…)) {x ∈ R | ∃ y ∈ EC(Individual(…)) : <x,y> ∈ ER(p) }

3.3. Interpreting Axioms and Facts

An Abstract OWL interpretation, I, satisfies OWL axioms and facts as given in Axiom and Fact Interpretation Table. In the table, optional parts of axioms and facts are given in square brackets ([…]) and have corresponding optional conditions, also given in square brackets.

Interpretation of Axioms and Facts
DirectiveConditions on interpretations
Class(c [Deprecated] complete
    annotation(p1 o1)annotation(pk ok)
    descr1 … descrn)
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ]
S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok))
EC(c) = EC(descr1) ∩…∩ EC(descrn)
Class(c [Deprecated] partial
    annotation(p1 o1)annotation(pk ok)
    descr1 … descrn)
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ]
S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok))
EC(c) ⊆ EC(descr1) ∩…∩ EC(descrn)
EnumeratedClass(c [Deprecated]
    annotation(p1 o1)annotation(pk ok)
    i1 … in)
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ]
S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok))
EC(c) = { S(i1), …, S(in) }
Datatype(c [Deprecated]
    annotation(p1 o1)annotation(pk ok) )
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ]
S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok))
EC(c) ⊆ LV
DisjointClasses(d1 … dn) EC(di) ∩ EC(dj) = { } for 1 ≤ i < j ≤ n
EquivalentClasses(d1 … dn) EC(di) = EC(dj) for 1 ≤ i < j ≤ n
SubClassOf(d1 d2) EC(d1) ⊆ EC(d2)
DatatypeProperty(p [Deprecated]
    annotation(p1 o1)annotation(pk ok)
    super(s1)super(sn)
    domain(d1)domain(dn) range(r1)range(rn)
    [Functional])
[ <S(c),S(owl:DeprecatedProperty)> ∈ ER(rdf:type) ]
S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok))
ER(p) ⊆ O×LV ∩ ER(s1) ∩…∩ ER(sn) ∩
       EC(d1)×LV ∩…∩ EC(dn)×LV ∩ O×EC(r1) ∩…∩ O×EC(rn)
[ER(p) is functional]
ObjectProperty(p [Deprecated]
    annotation(p1 o1)annotation(pk ok)
    super(s1)super(sn)
   
domain(d1)domain(dn) range(r1)range(rn)
   
[inverse(i)] [Symmetric]
    [
Functional] [ InverseFunctional]
    [
Transitive])
[ <S(c),S(owl:DeprecatedProperty)> ∈ ER(rdf:type)]
S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok))
ER(p) ⊆ O×O ∩ ER(s1) ∩…∩ ER(sn) ∩
        EC(d1O ∩…∩ EC(dnOO×EC(r1) ∩…∩ O×EC(rn)
[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]
AnnotationProperty(p annotation(p1 o1)annotation(pk ok)) S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok))
OntologyProperty(p annotation(p1 o1)annotation(pk ok)) S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok))
EquivalentProperties(p1 … pn) ER(pi) = ER(pj) for 1 ≤ i < j ≤ n
SubPropertyOf(p1 p2) ER(p1) ⊆ ER(p2)
SameIndividual(i1 … in) S(ij) = S(ik) for 1 ≤ j < k ≤ n
DifferentIndividuals(i1 … in) S(ij) ≠ S(ik) for 1 ≤ j < k ≤ n
Individual([i] annotation(p1 o1)annotation(pk ok)
   type(c1)type(cm) pv1 … pvn)
EC(Individual([i] annotation(p1 o1)annotation(pk ok)
   type(c1)type(cm) pv1 … pvn)) is nonempty

3.4. Interpreting Ontologies

From Section 2, an OWL ontology can have annotations, which need their own semantic conditions. Aside from this local meaning, an owl:imports annotation also imports the contents of another OWL ontology into the current ontology. The imported ontology is the one, if any, that has as name the argument of the imports construct. (This treatment of imports is divorced from Web issues. The intended use of names for OWL ontologies is to make the name be the location of the ontology on the Web, but this is outside of this formal treatment.)

Definition: Let D be a datatype map. An Abstract OWL interpretation, I, with respect to D with vocabulary consisting of VL, VC, VD, VI, VDP, VIP, VAP, VO, satisfies an OWL ontology, O, iff

  1. each URI reference in O used as a class ID (datatype ID, individual ID, data-valued property ID, individual-valued property ID, annotation property ID, annotation ID, ontology ID) belongs to VC (VD, VI, VDP, VIP, VAP, VO, respectively);
  2. each literal in O belongs to VL;
  3. I satisfies each directive in O, except for Ontology Annotations;
  4. there is some o ∈ R with <o,S(owl:Ontology)> ∈ ER(rdf:type) such that for each Ontology Annotation of the form Annotation(p v), <o,S(v)> ∈ ER(p) and that if O has name n, then S(n) = o; and
  5. I satisfies each ontology mentioned in an owl:imports annotation directive of O.

Definition: A collection of abstract OWL ontologies and axioms and facts is consistent with respect to datatype map D iff there is some interpretation I with respect to D such that I satisfies each ontology and axiom and fact in the collection.

Definition: A collection O of abstract OWL ontologies and axioms and facts entails an abstract OWL ontology or axiom or fact O' with respect to a datatype map D if each interpretation with respect to map D that satisfies each ontology and axiom and fact in O also satisfies O'.


4. Mapping to RDF Graphs (Normative)

This section of the document provides a mapping from the abstract syntax for OWL DL and OWL Lite given in Section 2 to the exchange syntax for OWL, namely RDF/XML [RDF Syntax]. This mapping (and its inverse) provide the normative relationship between the abstract syntax and the exchange syntax. It is shown in Section 5 and Appendix A.1 that this mapping preserves the meaning of OWL DL ontologies. Section 4.2 defines the OWL DL and OWL Lite dialects of OWL as those RDF graphs that are the result of mappings from abstract syntax ontologies.

The exchange syntax for OWL is RDF/XML [RDF Syntax], as specified in the OWL Reference Description [OWL Reference]. Further, the meaning of an OWL ontology in RDF/XML is determined only from the RDF graph [RDF Concepts] that results 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 triples. As all OWL Lite constructs are special cases of constructs in the full abstract syntax, transformations are only provided for the OWL DL versions.

OWL DL has semantics defined over the abstract syntax and a concrete syntax consisting of a subset of RDF graphs. Hence it is necessary to relate specific abstract syntax ontologies with specific RDF/XML documents and their corresponding graphs. This section defines a many-to-many relationship between abstract syntax ontologies and RDF graphs. This is done using a set of nondeterministic mapping rules. Thus to apply the semantics to a particular RDF graph it is necessary to find one of the abstract syntax ontologies that correspond with that graph under the mapping rules and to apply the semantics to that abstract ontology. The mapping is designed so that any of the RDF graphs that correspond to a particular abstract ontology have the same meaning, as do any of the abstract ontologies that correspond to a particular RDF graph. Moreover, since this process cannot be applied to RDF graphs that do not have corresponding abstract syntax forms, the mapping rules implicitly define a set of graphs, which syntactically characterize OWL DL in RDF/XML.

The syntax for triples used here is the one used in the RDF semantics [RDF MTSemantics]. In this variant, qualified names are allowed. As detailed in the RDF semantics, to turn this syntax into the standard one just expand the qualified names into URI references in the standard RDF manner by concatenating the namespace name with the local name, using the standard OWL namespaces.

4.1. Translation to RDF Graphs

The Transformation Table gives transformation rules that transform the abstract syntax to the OWL exchange syntax. In a few cases, notably for the DifferentIndividuals construct, there are different transformation rules. In such cases either rule can be chosen, resulting in a non-deterministic translation. In a few other cases, notably for class and property axioms, there are triples that may or may not be generated. These triples are indicated by flagging them with [opt]. In a couple of cases one of two triples must be generated. This is indicated by separating the triples with OR. These non-determinisms allow the generation of more RDF Graphs.

The left column of the table gives a piece of abstract syntax (S); the center column gives its transformation into triples (T(S)); and the right column gives an identifier for the main node of the transformation (M(T(S))), for syntactic constructs that can occur as pieces of directives. Repeating components are listed using ellipses, as in description1 … descriptionn, this form allows easy specification of the transformation for all values of n allowed in the syntax. Optional portions of the abstract syntax (enclosed in square brackets) are optional portions of the transformation (signified by square brackets). As well, for any of the built-in OWL datatypes, built-in OWL classes, built-in OWL annotation properties, and built-in OWL ontology properties the first rdf:type triple in the translation of it or any axiom for it is optional.

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 as the subject, predicate, or object of a triple, even an optional triple, the transformation of the component is part of the production (but only once per production) and the main node of that transformation should be used in 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. Ontologies without a name are given a bnode as their main node; ontologies with a name use that name as their main node; in both cases this node is referred to as O below.

Transformation to Triples
Abstract Syntax (and sequences) - S Transformation - T(S) Main Node - M(T(S))
Ontology(O directive1 … directiven) O rdf:type owl:Ontology .
T(directive1) … T(directiven)
Ontology(directive1 … directiven) O rdf:type owl:Ontology .
T(directive1) … T(directiven)
Annotation(ontologyPropertyID URIreference) ontologyPropertyID rdf:type owl:OntologyProperty .
O ontologyPropertyID URIreference .
URIreference rdf:type owl:Ontology .
Annotation(annotationPropertyID URIreference) annotationPropertyID rdf:type owl:AnnotationProperty .
annotationPropertyID rdf:type rdf:Property . [opt]
O annotationPropertyID URIreference .
Annotation(annotationPropertyID dataLiteral) annotationPropertyID rdf:type owl:AnnotationProperty .
annotationPropertyID rdf:type rdf:Property . [opt]
O annotationPropertyID T(dataLiteral) .
Annotation(annotationPropertyID individual) annotationPropertyID rdf:type owl:AnnotationProperty .
annotationPropertyID rdf:type rdf:Property . [opt]
O annotationPropertyID T(individual) .
rdfs:Literal rdfs:Literal
datatypeID datatypeID rdf:type rdfs:Datatype . datatypeID
classID classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
classID
individualID individualID
datavaluedPropertyID datavaluedPropertyID rdf:type owl:DatatypeProperty .
datavaluedPropertyID rdf:type rdf:Property . [opt]
datavalued-
PropertyID
individualvaluedPropertyID individualvaluedPropertyID rdf:type owl:ObjectProperty . [opt if there is a triple in the translation of the ontology that types the individualvaluedPropertyID as owl:InverseFunctionalProperty, owl:TransitiveProperty, or owl:SymmetricProperty] .
individualvaluedPropertyID rdf:type rdf:Property . [opt]
individualvalued-
PropertyID
dataLiteral dataLiteral dataLiteral
Individual(iID annotation1 … annotationm
      
type(type1)type(typen)
      value(pID1 v1)value(pIDk vk))
iID T(annotation1) … iID T(annotationm)
iID rdf:type T(type1) . … iID rdf:type T(typen) .
iID T(pID1) T(v1) . … iID T(pIDk) T(vk) .
iID
Individual(annotation1 … annotationm
      type(type1)type(typen)
      value(pID1 v1)value(pIDk vk))
(With at least one type.)
_:x T(annotation1) … _:x T(annotationm)
_:x rdf:type T(type1) . … _:x rdf:type T(typen) .
_:x T(pID1) T(v1) . … _:x T(pIDk) T(vk) .
_:x
Individual(annotation1 … annotationm
      value(pID1 v1)value(pIDk vk))
_:x T(annotation1) … _:x T(annotationm)
_:x rdf:type owl:Thing .
_:x T(pID1) T(v1) . … _:x T(pIDk) T(vk) .
_:x
SameIndividual(iID1 … iIDn) iIDi owl:sameAs iIDi+1 . 1≤i<n
iIDi owl:sameAs iIDj . [opt] 1≤i≠j≤n
DifferentIndividuals(iID1 … iIDn) iIDi owl:differentFrom iIDj . OR
iIDj owl:differentFrom iIDi . 1≤i<j≤n
iIDj owl:differentFrom iIDi . [opt] 1≤i≠j≤n
DifferentIndividuals(iID1 … iIDn) _:x rdf:type owl:AllDifferent .
_:x owl:distinctMembers T(SEQ iID1 … iIDn) .
Class(classID [Deprecated] partial
      annotation1 … annotationm
      description1 … descriptionn)
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
[classID rdf:type owl:DeprecatedClass .]
classID T(annotation1) … classID T(annotationm)
classID rdfs:subClassOf T(description1) . …
classID rdfs:subClassOf T(descriptionn) .
Class(classID [Deprecated] complete
      annotation1 … annotationm
      description1 … descriptionn)
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
[classID rdf:type owl:DeprecatedClass .]
classID T(annotation1) … classID T(annotationm)
classID owl:intersectionOf T(SEQ description1…descriptionn) .
Class(classID [Deprecated] complete
      annotation1 … annotationm
      description)
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
[classID rdf:type owl:DeprecatedClass .]
classID T(annotation1) … classID T(annotationm)
classID owl:equivalentClass T(description) .
Class(classID [Deprecated] complete
      annotation1 … annotationm
      unionOf(description1 … descriptionn))
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
[classID rdf:type owl:DeprecatedClass .]
classID T(annotation1) … classID T(annotationm)
classID owl:unionOf T(SEQ description1…descriptionn) .
Class(classID [Deprecated] complete
      annotation1 … annotationm
      complementOf(description))
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
[classID rdf:type owl:DeprecatedClass .]
classID T(annotation1) … classID T(annotationm)
classID owl:complementOf T(description) .
EnumeratedClass(classID [Deprecated]
      annotation1 … annotationm
      iID1 … iIDn)
classID rdf:type owl:Class .
classID rdf:type rdfs:Class . [opt]
[classID rdf:type owl:DeprecatedClass .]
classID T(annotation1) … classID T(annotationm) .
classID owl:oneOf T(SEQ iID1…iIDn) .
DisjointClasses(description1 … descriptionn) T(descriptioni) owl:disjointWith T(descriptionj) . OR
T(descriptionj) owl:disjointWith T(descriptioni) . 1≤i<j≤n
T(descriptioni) owl:disjointWith T(descriptionj) . [opt] 1≤i≠j≤n
EquivalentClasses(description1 … descriptionn) T(descriptioni) owl:equivalentClass T(descriptionj) .
for all <i,j> in G where G is a set of pairs over {1,...,n}x{1,...,n}
that if interpreted as an undirected graph forms a connected graph for {1,...,n}
SubClassOf(description1 description2) T(description1) rdfs:subClassOf T(description2) .
Datatype(datatypeID [Deprecated]
      annotation1 … annotationm )
datatypeID rdf:type rdfs:Datatype .
datatypeID rdf:type rdfs:Class . [opt]
[datatypeID rdf:type owl:DeprecatedClass .]
datatypeID T(annotation1) … datatypeID T(annotationm)
unionOf(description1 … descriptionn) _:x rdf:type owl:Class .
_:x rdf:type rdfs:Class . [opt]
_:x owl:unionOf T(SEQ description1…descriptionn) .
_:x
intersectionOf(description1 … descriptionn) _:x rdf:type owl:Class .
_:x rdf:type rdfs:Class . [opt]
_:x owl:intersectionOf T(SEQ description1…descriptionn) .
_:x
complementOf(description) _:x rdf:type owl:Class .
_:x rdf:type rdfs:Class . [opt]
_:x owl:complementOf T(description) .
_:x
oneOf(iID1 … iIDn) _:x rdf:type owl:Class .
_:x rdf:type rdfs:Class . [opt]
_:x owl:oneOf T(SEQ iID1…iIDn) .
_:x
oneOf(v1 … vn) _:x rdf:type owl:DataRange .
_:x rdf:type rdfs:Class . [opt]
_:x owl:oneOf T(SEQ v1 … vn) .
_:x
restriction(ID component1 … componentn)
(With at least two components)
_:x rdf:type owl:Class .
_:x rdf:type rdfs:Class . [opt]
_:x owl:intersectionOf
  T(SEQ(restriction(ID component1) … restriction(ID componentn))) .
_:x
restriction(ID allValuesFrom(range)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:allValuesFrom T(range) .
_:x
restriction(ID someValuesFrom(required)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:someValuesFrom T(required) .
_:x
restriction(ID value(value)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:hasValue T(value) .
_:x
restriction(ID minCardinality(min)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:minCardinality "min"^^xsd:nonNegativeInteger .
_:x
restriction(ID maxCardinality(max)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:maxCardinality "max"^^xsd:nonNegativeInteger .
_:x
restriction(ID cardinality(card)) _:x rdf:type owl:Restriction .
_:x rdf:type owl:Class . [opt]
_:x rdf:type rdfs:Class . [opt]
_:x owl:onProperty T(ID) .
_:x owl:cardinality "card"^^xsd:nonNegativeInteger .
_:x
DatatypeProperty(ID [Deprecated]
      annotation1 … annotationm
      super(super1)super(supern)
      domain(domain1)
      domain(domaink)
      range(range1)
      range(rangeh)
      [Functional])
ID rdf:type owl:DatatypeProperty .
ID rdf:type rdf:Property . [opt]
[ID rdf:type owl:DeprecatedProperty .]
ID T(annotation1) … ID T(annotationm)
ID rdfs:subPropertyOf T(super1) . …
ID rdfs:subPropertyOf T(supern) .
ID rdfs:domain T(domain1) . …
ID rdfs:domain T(domaink) .
ID rdfs:range T(range1) . …
ID rdfs:range T(rangeh) .
[ID rdf:type owl:FunctionalProperty . ]
ObjectProperty(ID [Deprecated]
      annotation1 … annotationm
      super(super1)super(supern)
      domain(domain1)
      domain(domaink)
      range(range1)
      range(rangeh)
      [inverseOf(inverse)]
      [Functional |
       InverseFunctional |
       Transitive])
      [Symmetric]
ID rdf:type owl:ObjectProperty .
    [opt if one of the last three triples is included]
ID rdf:type rdf:Property . [opt]
[ID rdf:type owl:DeprecatedProperty .]
ID T(annotation1) … ID T(annotationm)
ID rdfs:subPropertyOf T(super1) . …
ID rdfs:subPropertyOf T(supern) .
ID rdfs:domain T(domain1) . …
ID rdfs:domain T(domaink) .
ID rdfs:range T(range1) . …
ID rdfs:range T(rangeh) .
[ID owl:inverseOf T(inverse) .]
[ID rdf:type owl:FunctionalProperty . ]
[ID rdf:type owl:InverseFunctionalProperty . ]
[ID rdf:type owl:TransitiveProperty . ]
[ID rdf:type owl:SymmetricProperty . ]
AnnotationProperty(ID
      annotation1 … annotationm)
ID rdf:type owl:AnnotationProperty .
ID rdf:type rdf:Property . [opt]
ID T(annotation1) … ID T(annotationm)
OntologyProperty(ID
      annotation1 … annotationm)
ID rdf:type owl:OntologyProperty .
ID rdf:type rdf:Property . [opt]
ID T(annotation1) … ID T(annotationm)
EquivalentProperties(dvpID1 … dvpIDn) T(dvpIDi) owl:equivalentProperty T(dvpIDi+1) . 1≤i<n
SubPropertyOf(dvpID1 dvpID2) T(dvpID1) rdfs:subPropertyOf T(dvpID2) .
EquivalentProperties(ivpID1 … ivpIDn) T(ivpIDi) owl:equivalentProperty T(ivpIDi+1) . 1≤i<n
SubPropertyOf(ivpID1 ivpID2) T(ivpID1) rdfs:subPropertyOf T(ivpID2) .
annotation(annotationPropertyID URIreference) annotationPropertyID URIreference .
annotationPropertyID rdf:type owl:AnnotationProperty .
annotationPropertyID rdf:type rdf:Property . [opt]
annotation(annotationPropertyID dataLiteral) annotationPropertyID T(dataLiteral) .
annotationPropertyID rdf:type owl:AnnotationProperty .
annotationPropertyID rdf:type rdf:Property . [opt]
annotation(annotationPropertyID individual) annotationPropertyID T(individual) .
annotationPropertyID rdf:type owl:AnnotationProperty .
annotationPropertyID rdf:type rdf:Property . [opt]
SEQ rdf:nil
SEQ item1…itemn _:l1 rdf:type rdf:List . [opt]
_:l1 rdf:first T(item1) . _:l1 rdf:rest _:l2 .

_:ln rdf:type rdf:List . [opt]
_:ln rdf:first T(itemn) . _:ln rdf:rest rdf:nil .
_:l1

This transformation is not injective, as several OWL abstract ontologies that do not use the above reserved vocabulary can map into equal RDF graphs. 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.

4.2. Definition of OWL DL and OWL Lite Ontologies in RDF Graph Form

When considering OWL Lite and DL ontologies in RDF graph form, care must be taken to prevent the use of certain vocabulary as OWL classes, properties, or individuals. If this is not done the built-in definitions or use of this vocabulary (in the RDF or OWL specification) would augment the information in the OWL ontology. Only some of the RDF vocabulary fits in this category, as some of the RDF vocabulary, such as rdf:subject, is given little or no meaning by the RDF specifications and its use does not present problems, as long as the use is consistent with any meaning given by the RDF specifications.

Definition: The disallowed vocabulary from RDF is rdf:type, rdf:Property, rdf:nil, rdf:List, rdf:first, rdf:rest, rdfs:domain, rdfs:range, rdfs:Resource, rdfs:Datatype, rdfs:Class, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:member, rdfs:Container and rdfs:ContainerMembershipProperty. The disallowed vocabulary from OWL is owl:AllDifferent, owl:allValuesFrom, owl:AnnotationProperty, owl:cardinality, owl:Class, owl:complementOf, owl:DataRange, owl:DatatypeProperty, owl:DeprecatedClass, owl:DeprecatedProperty, owl:differentFrom, owl:disjointWith, owl:distinctMembers, owl:equivalentClass, owl:equivalentProperty, owl:FunctionalProperty, owl:hasValue, owl:intersectionOf, owl:InverseFunctionalProperty, owl:inverseOf, owl:maxCardinality, owl:minCardinality, owl:ObjectProperty, owl:oneOf, owl:onProperty, owl:Ontology, owl:OntologyProperty, owl:Restriction, owl:sameAs, owl:someValuesFrom, owl:SymmetricProperty, owl:TransitiveProperty, and owl:unionOf. The disallowed vocabulary is the union of the disallowed vocabulary from RDF and the disallowed vocabulary from OWL.

Definition: The class-only vocabulary is rdf:Statement, rdf:Seq, rdf:Bag, and rdf:Alt. The datatype-only vocabulary is the built-in OWL datatypes. The property-only vocabulary is rdf:subject, rdf:predicate, rdf:object, and all the container membership properties, i.e., rdf:_1, rdf:_2, ….

Definition: A collection of OWL DL ontologies and axioms and facts in abstract syntax form, O, has a separated vocabulary if

  1. the ontologies in O, taken together, do not use any URI reference as more than one of a class ID, a datatype ID, an individual ID, an individual-valued property ID, a data-valued property ID, an annotation property ID, an ontology property ID, or an ontology ID;
  2. the ontologies in O, taken together, provide a type for every individual ID;
  3. the ontologies in OO, except as the values of annotations, only use the class-only vocabulary as class IDs; only use the datatype-only vocabulary as datatype IDs; only use rdfs:Literal in data ranges; only use the property-only vocabulary as datavaluedProperty IDs, individualvaluedProperty IDs, or annotationProperty IDs; only use the built-in classes as class IDs; only use the built-in datatypes as datatype IDs; only use the built-in annotation properties as annotationProperty IDs; only use the built-in ontology properties as ontologyProperty IDs; and do not mention any disallowed vocabulary.

Definition: An RDF graph is an OWL DL ontology in RDF graph form if it is equal (see below for a slight relaxation) to a result of the transformation to triples above of a collection of OWL DL ontologies and axioms and facts in abstract syntax form that has a separated vocabulary. For the purposes of determining whether an RDF graph is an OWL DL ontology in RDF graph form, cardinality restrictions are explicitly allowed to use constructions like "1"^^xsd:integer so long as the data value so encoded is a non-negative integer.

Definition: An RDF graph is an OWL Lite ontology in RDF graph form if it is as above except that the contents of O are OWL Lite ontologies or axioms or facts in abstract syntax form.


5. RDF-Compatible Model-Theoretic Semantics (Normative)

This model-theoretic semantics for OWL is an extension of the semantics defined in the RDF semantics [RDF MTSemantics], and defines the OWL semantic extension of RDF.

NOTE: There is a strong correspondence between the semantics for OWL DL defined in this section and the Direct Model-Theoretic Semantics defined in Section 3 (see Theorem 1 and Theorem 2 in Section 5.4). If, however, any conflict should ever arise between these two forms, then the Direct Model-Theoretic Semantics takes precedence.

5.1. The OWL and RDF universes

All of the OWL vocabulary is defined on the 'OWL universe', which is a division of part of the RDF universe into three parts, namely OWL individuals, classes, and properties. The class extension of owl:Thing comprises the individuals of the OWL universe. The class extension of owl:Class comprises the classes of the OWL universe. The union of the class extensions of owl:ObjectProperty, owl:DatatypeProperty, owl:AnnotationProperty, and owl:OntologyProperty comprises the properties of the OWL universe.

There are two different styles of using OWL. In the more free-wheeling style, called OWL Full, the three parts of the OWL universe are identified with their RDF counterparts, namely the class extensions of rdfs:Resource, rdfs:Class, and rdf:Property. In OWL Full, as in RDF, elements of the OWL universe 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, the three parts are different from their RDF counterparts and, moreover, pairwise disjoint. The more-restrictive OWL DL style gives up some expressive power in return for decidability of entailment. Both styles of OWL provide entailments that are missing in a naive translation of the DAML+OIL model-theoretic semantics into the RDF semantics.

A major difference in practice between the two styles lies in the care that is required to ensure that URI references are actually in the appropriate part of the OWL universe. In OWL Full, no care is needed. In OWL DL, localizing 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, which corresponds closely to OWL DL. But when writing OWL DL in triples, however, close attention must be paid to which elements of the vocabulary belong to which part of the OWL universe.

Throughout this section the OWL vocabulary will be the disallowed vocabulary from OWL plus the built-in classes, the built-in annotation properties, and the built-in ontology properties.

5.2. OWL Interpretations

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 semantics [RDF MTSemantics], for V a set of URI references and literals containing the RDF and RDFS vocabulary and D a datatype map, a D-interpretation of V is a tuple I = < RI, PI, EXTI, SI, LI, LVI >. RI is the domain of discourse or universe, i.e., a nonempty set that contains the denotations of URI references and literals in V. PI is a subset of RI, the properties of I. EXTI is used to give meaning to properties, and is a mapping from PI to P(RI × RI). SI is a mapping from URI references in V to their denotations in RI. LI is a mapping from typed literals in V to their denotations in RI. LVI is a subset of RI that contains at least the set of Unicode strings, the set of pairs of Unicode strings and language tags, and the value spaces for each datatype in D. The set of classes CI is defined as CI = { x ∈RI | <x,SI(rdfs:Class)> ∈ EXTI(SI(rdf:type)) }, and the mapping CEXTI from CI to P(RI) is defined as CEXTI(c) = { x∈RI | <x,c>∈EXTI(SI(rdf:type)) }. D-interpretations must meet several other conditions, as detailed in the RDF semantics. For example, EXTI(SI(rdfs:subClassOf)) must be a transitive relation and the class extension of all datatypes must be subsets of LVI.

Definition: Let D be a datatype map that includes datatypes for rdf:XMLLiteral, xsd:integer and xsd:string. An OWL interpretation, I = < RI, PI, EXTI, SI, LI, LVI >, of a vocabulary V, where V includes the RDF and RDFS vocabularies and the OWL vocabulary, is a D-interpretation of V that satisfies all the constraints in this section.

Note: Elements of the OWL vocabulary that construct descriptions in the abstract syntax are given a different treatment from elements of the OWL vocabulary that correspond to (other) semantic relationships. The former have only-if semantic conditions and comprehension principles; the latter have if-and-only-if semantic conditions. The only-if semantic conditions for the former are needed to prevent semantic paradoxes and other problems with the semantics. The comprehension principles for the former and the if-and-only-if semantic conditions for the latter are needed so that useful entailments are valid.

Conditions concerning the parts of the OWL universe and syntactic categories

If E is then Note
SI(E)∈ CEXTI(SI(E))= and
owl:Class CIIOCIOC⊆CI This defines IOC as the set of OWL classes.
rdfs:Datatype IDCIDC⊆CI This defines IDC as the set of OWL datatypes.
owl:RestrictionCIIORIOR⊆IOC This defines IOR as the set of OWL restrictions.
owl:Thing IOCIOT IOT⊆RI and IOT ≠ ∅ This defines IOT as the set of OWL individuals.
owl:Nothing IOC{}
rdfs:Literal IDCLVILVI⊆RI
owl:ObjectProperty CIIOOPIOOP⊆PI This defines IOOP as the set of OWL individual-valued properties.
owl:DatatypeProperty CIIODPIODP⊆PI This defines IODP as the set of OWL datatype properties.
owl:AnnotationProperty CIIOAPIOAP⊆PI This defines IOAP as the set of OWL annotation properties.
owl:OntologyProperty CIIOXPIOXP⊆PI This defines IOXP as the set of OWL ontology properties.
owl:Ontology CIIX This defines IX as the set of OWL ontologies.
owl:AllDifferent CIIAD
rdf:List ILIL⊆RI This defines IL as the set of OWL lists.
rdf:nilIL
"l"^^d CEXTI(SI(d)) SI("l"^^d) ∈ LVI Typed literals are well-behaved in OWL.

OWL built-in syntactic classes and properties

I(owl:FunctionalProperty), I(owl:InverseFunctionalProperty), I(owl:SymmetricProperty), I(owl:TransitiveProperty), I(owl:DeprecatedClass), and I(owl:DeprecatedProperty) are in CI.

I(owl:equivalentClass), I(owl:disjointWith), I(owl:equivalentProperty), I(owl:inverseOf), I(owl:sameAs), I(owl:differentFrom), I(owl:complementOf), I(owl:unionOf), I(owl:intersectionOf), I(owl:oneOf), I(owl:allValuesFrom), I(owl:onProperty), I(owl:someValuesFrom), I(owl:hasValue), I(owl:minCardinality), I(owl:maxCardinality), I(owl:cardinality), and I(owl:distinctMembers) are all in PI.

I(owl:versionInfo), I(rdfs:label), I(rdfs:comment), I(rdfs:seeAlso), and I(rdfs:isDefinedBy) are all in IOAP. I(owl:imports), I(owl:priorVersion), I(owl:backwardCompatibleWith), and I(owl:incompatibleWith), are all in IOXP.

Characteristics of OWL classes, datatypes, and properties

If E is then if e∈CEXTI(SI(E)) then Note
owl:ClassCEXTI(e)⊆IOT Instances of OWL classes are OWL individuals.
rdfs:DatatypeCEXTI(e)⊆LVI
owl:DataRange CEXTI(e)⊆LVI OWL dataranges are special kinds of datatypes.
owl:ObjectPropertyEXTI (e)⊆IOTIOT(e)⊆IOT×IOT Values for individual-valued properties are OWL individuals.
owl:DatatypePropertyEXTI (e)⊆IOTLV(e)⊆IOT×LVI Values for datatype properties are literal values.
owl:AnnotationPropertyEXTI (e)⊆IOT(IOT∪LV(e)⊆IOT×(IOT∪LVI) Values for annotation properties are less unconstrained.
owl:OntologyPropertyEXTI (e)⊆IXIX(e)⊆IX×IX Ontology properties relate ontologies to other ontologies.
If E is then c∈CEXTI(SI(E)) iff c∈IOOP∪IODP and Note
owl:FunctionalProperty <x,y1>, <x,y2> ∈ EXTI(c) implies y1 = y2 Both individual-valued and datatype properties can be functional properties.
If E is then c∈CEXTI(SI(E)) iff c∈IOOP and Note
owl:InverseFunctionalProperty <x1,y>, <x2,y>∈EXTI(c) implies x1 = x2 Only individual-valued properties can be inverse functional properties.
owl:SymmetricProperty <x,y> ∈ EXTI(c) implies <y, x>∈EXTI(c) Only individual-valued properties can be symmetric properties.
owl:TransitiveProperty <x,y>, <y,z>∈EXTI(c) implies <x,z>∈EXTI(c) Only individual-valued properties can be transitive properties.

If-and-only-if conditions for rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain, and rdfs:range

If E is then for<x,y>∈EXTI(SI(E)) iff
rdfs:subClassOf x,y∈IOC CEXTI(x) ⊆ CEXTI(y)
rdfs:subPropertyOf x,y∈IOOP EXTI(x) ⊆ EXTI(y)
rdfs:subPropertyOf x,y∈IODP EXTI(x) ⊆ EXTI(y)
rdfs:domain x∈IOOP∪IODP,y∈IOC <z,w>∈EXTI(x) implies z∈CEXTI(y)
rdfs:range x∈IOOP∪IODP,y∈IOC∪IDC <w,z>∈EXTI(x) implies z∈CEXTI(y)

Characteristics of OWL vocabulary related to equivalence

If E is then <x,y>∈EXTI(SI(E)) iff
owl:equivalentClass x,y∈IOC and CEXTI(x)=CEXTI(y)
owl:disjointWith x,y∈IOC and CEXTI(x)∩CEXTI(y)={}
owl:equivalentProperty x,y∈IOOP∪IODP and EXTI(x) = EXTI(y)
owl:inverseOf x,y∈IOOP and <u,v>∈EXTI(x) iff <v,u>∈EXTI(y)
owl:sameAs x = y
owl:differentFrom x ≠ y

Conditions on OWL vocabulary related to boolean combinations and sets

We will say that l1 is a sequence of y1,…,yn over C iff n=0 and l1=SI(rdf:nil) or n>0 and l1∈IL and ∃ l2, …, ln ∈ IL such that
<l1,y1>∈EXTI(SI(rdf:first)), y1∈C, <l1,l2>∈EXTI(SI(rdf:rest)), …,
<ln,yn>∈EXTI(SI(rdf:first)), yn∈C, and <ln,SI(rdf:nil)>∈EXTI(SI(rdf:rest)).

If E is then <x,y>∈EXTI(SI(E)) iff
owl:complementOf x,y∈ IOC and CEXTI(x)=IOT-CEXTI(y)
owl:unionOf x∈IOC and y is a sequence of y1,…yn over IOC and CEXTI(x) = CEXTI(y1)∪…∪CEXTI(yn)
owl:intersectionOf x∈IOC and y is a sequence of y1,…yn over IOC and CEXTI(x) = CEXTI(y1)∩…∩CEXTI(yn)
owl:oneOf x∈CI and y is a sequence of y1,…yn over IOT or over LVI and CEXTI(x) = {y1,..., yn}

Further conditions on owl:oneOf

If E isand then if <x,l>∈EXTI(SI(E)) then
owl:oneOfl is a sequence of y1,…yn over LVI x∈IDC
owl:oneOfl is a sequence of y1,…yn over IOT x∈IOC

Conditions on OWL restrictions

If then x∈IOR, y∈IOC∪IDC, p∈IOOP∪IODP, and CEXTI(x) =
<x,y>∈EXTI(SI(owl:allValuesFrom))) ∧
<x,p>∈EXTI(SI(owl:onProperty)))
{u∈IOT | <u,v>∈EXTI(p) implies v∈CEXTI(y) }
<x,y>∈EXTI(SI(owl:someValuesFrom))) ∧
<x,p>∈EXTI(SI(owl:onProperty)))
{u∈IOT | ∃ <u,v>∈EXTI(p) such that v∈CEXTI(y) }
If then x∈IOR, y∈IOT∪LVI, p∈IOOP∪IODP, and CEXTI(x) =
<x,y>∈EXTI(SI(owl:hasValue))) ∧
<x,p>∈EXTI(SI(owl:onProperty)))
{u∈IOT | <u, y>∈EXTI(p) }
If then x∈IOR, y∈LVI, y is a non-negative integer, p∈IOOP∪IODP, and CEXTI(x) =
<x,y>∈EXTI(SI(owl:minCardinality))) ∧
<x,p>∈EXTI(SI(owl:onProperty)))
{u∈IOT | card({v ∈ IOT ∪ LV : <u,v>∈EXTI(p)}) ≥ y }
<x,y>∈EXTI(SI(owl:maxCardinality))) ∧
<x,p>∈EXTI(SI(owl:onProperty)))
{u∈IOT | card({v ∈ IOT ∪ LV : <u,v>∈EXTI(p)}) ≤ y }
<x,y>∈EXTI(SI(owl:cardinality))) ∧
<x,p>∈EXTI(SI(owl:onProperty)))
{u∈IOT | card({v ∈ IOT ∪ LV : <u,v>∈EXTI(p)}) = y }

Comprehension conditions (principles)

The first two comprehension conditions require the existence of the finite sequences that are used in some OWL constructs. The third comprehension condition requires the existence of instances of owl:AllDifferent. The remaining comprehension conditions require the existence of the appropriate OWL descriptions and data ranges.

If there exists then there exists l1,…,ln ∈ IL with
x1, …, xn ∈ IOC <l1,x1> ∈ EXTI(SI(rdf:first)), <l1,l2> ∈ EXTI(SI(rdf:rest)), …
<ln,xn> ∈ EXTI(SI(rdf:first)), <ln,SI(rdf:nil)> ∈ EXTI(SI(rdf:rest))
x1, …, xn ∈ IOT∪LVI <l1,x1> ∈ EXTI(SI(rdf:first)), <l1,l2> ∈ EXTI(SI(rdf:rest)), …
<ln,xn> ∈ EXTI(SI(rdf:first)), <ln,SI(rdf:nil)> ∈ EXTI(SI(rdf:rest))
If there exists then there exists y with
l, a sequence of x1,…,xn over IOT
with xi≠xj for 1≤i<j≤n
y∈IAD, <y,l>∈EXTI(SI(owl:distinctMembers))
If there exists then there exists y with
l, a sequence of x1,…,xn over IOC y∈IOC, <y,l> ∈ EXTI(SI(owl:unionOf))
l, a sequence of x1,…,xn over IOC y∈IOC, <y,l> ∈ EXTI(SI(owl:intersectionOf))
l, a sequence of x1,…,xn over IOT y∈IOC, <y,l> ∈ EXTI(SI(owl:oneOf))
l, a sequence of x1,…,xn over LVI y∈IDC, <y,l> ∈ EXTI(SI(owl:oneOf))
If there exists then there exists y ∈ IOC with
x ∈ IOC <y,x> ∈ EXTI(SI(owl:complementOf))
If there exists then there exists y ∈ IOR with
x ∈ IOOP∪IODP ∧ w ∈ IOC ∪ IDC <y,x> ∈ EXTI(SI(owl:onProperty)) ∧
<y,w> ∈ EXTI(SI(owl:allValuesFrom))
x ∈ IOOP∪IODP ∧ w ∈ IOC ∪ IDC <y,x> ∈ EXTI(SI(owl:onProperty)) ∧
<y,w> ∈ EXTI(SI(owl:someValuesFrom))
x ∈ IOOP∪IODP ∧ w ∈ IOT ∪ LVI <y,x> ∈ EXTI(SI(owl:onProperty)) ∧
<y,w> ∈ EXTI(SI(owl:hasValue))
x ∈ IOOP∪IODP ∧ w ∈ LVI ∧ w is a non-negative integer <y,x> ∈ EXTI(SI(owl:onProperty)) ∧
<y,w> ∈ EXTI(SI(owl:minCardinality))
x ∈ IOOP∪IODP ∧ w ∈ LVI ∧ w is a non-negative integer <y,x> ∈ EXTI(SI(owl:onProperty)) ∧
<y,w> ∈ EXTI(SI(owl:maxCardinality))
x ∈ IOOP∪IODP ∧ w ∈ LVI ∧ w is a non-negative integer <y,x> ∈ EXTI(SI(owl:onProperty)) ∧
<y,w> ∈ EXTI(SI(owl:cardinality))

5.3. OWL Full

OWL Full augments the common conditions with conditions that force the parts of the OWL universe to be the same as their analogues in RDF. These new conditions strongly interact with the common conditions. For example, because in OWL Full IOT is the entire RDF domain of discourse, the second comprehension condition for lists generates lists of any kind, including lists of lists.

Definition: An OWL Full interpretation of a vocabulary V is an OWL interpretation that satisfies the following conditions (recall that an OWL interpretation is with respect to a datatype map).

IOT = RI
IOOP = PI
IOC = CI

Definition: Let K be a collection of RDF graphs. K is imports closed iff for every triple in any element of K of the form x owl:imports u . then K contains a graph that is the result of the RDF processing of the RDF/XML document, if any, accessible at u into an RDF graph. The imports closure of a collection of RDF graphs is the smallest import-closed collection of RDF graphs containing the graphs.

Definitions: Let K and Q be collections of RDF graphs and D be a datatype map. Then K OWL Full entails Q with respect to D iff every OWL Full interpretation with respect to D (of any vocabulary V that includes the RDF and RDFS vocabularies and the OWL vocabulary) that satisfies all the RDF graphs in K also satisfies all the RDF graphs in Q. K is OWL Full consistent iff there is some OWL Full interpretation that satisfies all the RDF graphs in K.

5.4. OWL DL

OWL DL augments the conditions of Section 5.2 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 first-order, in that predicates (classes and properties) and individuals 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.

Definition: A OWL DL interpretation of a vocabulary V is an OWL interpretation that satisfies the following conditions (recall that an OWL interpretation is with respect to a datatype map).

LVI, IOT, IOC, IDC, IOOP, IODP, IOAP, IOXP, IL, and IX are all pairwise disjoint.
For v in the disallowed vocabulary (Section 4.2), SI(v) ∈ RI - (LVI∪IOT∪IOC∪IDC∪IOOP∪IODP∪IOAP∪IOXP∪IL∪IX).

Entailment in OWL DL is defined similarly to entailment in OWL Full.

Definitions: Let K and Q be collections of RDF graphs and D be a datatype map. Then K OWL DL entails Q with respect to D iff every OWL DL interpretation with respect to D (of any vocabulary V that includes the RDF and RDFS vocabularies and the OWL vocabulary) that satisfies all the RDF graphs in K also satisfies all the RDF graphs in Q. K is OWL DL consistent iff there is some OWL DL interpretation that satisfies all the RDF graphs in K.

There is a strong correspondence between the Direct Model-Theoretic Semantics and the OWL DL semantics (but in case of any conflict, the Direct Model-Theoretic Semantics takes precedence—see the Note at the beginning of Section 5). Basically, an ontology that could be written in the abstract syntax OWL DL entails another exactly when it entails the other in the direct semantics. There are a number of complications to this basic story having to do with splitting up the vocabulary so that, for example, concepts, properties, and individuals do not interfere, and arranging that imports works the same.

For the correspondence to be valid there has to be some connection between an ontology in the abstract syntax with a particular name and the document available on the Web at that URI. This connection is outside the semantics here, and so must be specially arranged. This connection is also only an idealization of the Web, as it ignores temporal and transport aspects of the Web.

Definition: Let T be the mapping from the abstract syntax to RDF graphs from Section 4.1. Let O be a collection of OWL DL ontologies and axioms and facts in abstract syntax form. O is said to be imports closed iff for any URI, u, in an imports directive in any ontology in O the RDF parsing of the document accessible on the Web at u results in T(K), where K is the ontology in O with name u.

Theorem 1: Let O and O' be collections of OWL DL ontologies and axioms and facts in abstract syntax form that are imports closed, such that their union has a separated vocabulary (Section 4.2). Given a datatype map D that maps xsd:string and xsd:integer to the appropriate XML Schema datatypes and that includes the RDF mapping for rdf:XMLLiteral, then O entails O' with respect to D if and only if the translation (Section 4.1) of O OWL DL entails the translation of O' with respect to D.
The proof is contained in Appendix A.1.

A simple corollary of this is that, given a datatype map D that maps xsd:string and xsd:integer to the appropriate XML Schema datatypes and that includes the RDF mapping for rdf:XMLLiteral, O is consistent with respect to D if and only if the translation of O is consistent with respect to D.

There is also a correspondence between OWL DL entailment and OWL Full entailment.

Theorem 2: Let O and O' be collections of OWL DL ontologies and axioms and facts in abstract syntax form that are imports closed, such that their union has a separated vocabulary (Section 4.2). Given a datatype map D that maps xsd:string and xsd:integer to the appropriate XML Schema datatypes and that includes the RDF mapping for rdf:XMLLiteral, then the translation of O OWL Full entails the translation of O' with respect to D if the translation of O OWL DL entails the translation of O' with respect to D. A sketch of the proof is contained in Appendix A.2.


Appendix A. Proofs (Informative)

This appendix contains proofs of theorems contained in Section 5 of the document.

Nomenclature: Throughout this appendix D will be a datatype map (Section 3.1) containing datatypes for all the built-in OWL datatypes and rdf:XMLLiteral; T will be the mapping from abstract OWL ontologies to RDF graphs from Section 4.1; and VB will be the built-in OWL vocabulary. Also, the plain literals in a vocabulary will not be mentioned.

Note: Throughout this appendix all interpretations are with respect to the datatype map D. Thus all results are with respect to D. Some of the obvious details of the constructions are missing.

A.1 Correspondence between Abstract OWL and OWL DL

This section shows that the two semantics, the direct model theory for abstract OWL ontologies from Section 3, here called the direct model theory, and the OWL DL semantics from Section 5, here called the OWL DL model theory, correspond on certain OWL ontologies.

Definition: Given D as above, a separated OWL vocabulary (Section 4.2) is here further formalized into a set of URI references V', disjoint from the disallowed vocabulary (Section 4.2), with a disjoint partition of V', written as V' = VO + VC + VD + VI + VOP + VDP + VAP + VXP, where the built-in OWL classes are in VC, the URI references all the datatype names of D and rdfs:Literal are in VD, the OWL built-in annotation properties are in VAP, and the OWL built-in ontology properties are in VXP.

Definition: The translation of a separated OWL vocabulary, V' = VO + VC + VD + VI + VOP + VDP + VAP + VXP, written T(V'), consists of all the triples of the form
v rdf:type owl:Ontology . for v ∈ VO,
v rdf:type owl:Class . for v ∈ VC,
v rdf:type rdfs:Datatype . for v ∈ VD,
v rdf:type owl:Thing . for v ∈ VI,
v rdf:type owl:ObjectProperty . for v ∈ VOP,
v rdf:type owl:DatatypeProperty . for v ∈ VDP,
v rdf:type owl:AnnotationProperty . for v ∈ VAP, and
v rdf:type owl:OntologyProperty . for v ∈ VXP.

Definition: A collection of OWL DL ontologies and axioms and facts in abstract syntax form, O, (Section 2) with a separated vocabulary (Section 4) is here further formalized with the new notion of a separated vocabulary V = VO + VC + VD + VI + VOP + VDP + VAP + VXP, as follows:

The theorem to be proved is then: Let O and O' be collections of OWL DL ontologies and axioms and facts in abstract syntax form that are imports closed, such that their union has a separated vocabulary. Then O direct entails O' if and only if T(O) OWL DL entails T(O').

A.1.1 Correspondence for Descriptions

Lemma 1: Let V' = VO + VC + VD + VI + VOP + VDP + VAP + VXP be a separated OWL vocabulary. Let V = VO ∪ VC ∪ VD ∪ VI ∪ VOP ∪ VDP ∪ VAP ∪ VXP ∪ VB. Let I'= <R,EC,ER,L,S,LV> be a direct interpretation of V'. Let I = <RI,PI,EXTI,SI,LI,LVI> be a OWL DL interpretation of V that satisfies T(V'), with LVI = LV. Let CEXTI have its usual meaning, and, as usual, overload I to map any syntactic construct into its denotation. If

then for d any abstract OWL description or data range over V',

  1. I direct satisfies T(d), and
  2. for any A mapping all the blank nodes of T(d) into RI where I+A OWL DL satisfies T(d)
    1. CEXTI(I+A(M(T(d)))) = EC(d),
    2. if d is a description then I+A(M(T(d)))∈CEXTI(SI(owl:Class)), and
    3. if d is a data range then I+A(M(T(d)))∈CEXTI(SI(rdfs:Datatype)).

Proof:

The proof of the lemma is by a structural induction. Throughout the proof, let IOT = CEXTI(I(owl:Thing)), IOC = CEXTI(I(owl:Class)), IDC = CEXTI(I(rdfs:Datatype)), IOOP = CEXTI(I(owl:ObjectProperty)), IODP = CEXTI(I(owl:DatatypeProperty)), and IL = CEXTI(I(rdf:List)).

To make the induction work, it is necessary to show that for any d a description or data range with sub-constructs T(d) contains triples for each of the sub-constructs that do not share any blank nodes with triples from the other sub-constructs. 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,I(owl:Thing)>∈EXTI(I(rdfs:domain)) and <p,I(owl:Thing)>∈EXTI(I(rdfs:range)). Thus I satisfies T(p). Similarly for p∈VDP.

Base Case: v ∈ VC, including owl:Thing and owl:Nothing
As v∈VC and I satisfies T(V), thus I(v)∈CEXTI(I(owl:Class)). Because I is an OWL DL interpretation CEXTI(I(v))⊆IOT, so <I(v),I(owl:Thing)>∈EXTI(I(rdfs:subClassOf)). Thus I OWL DL satisfies T(v). As M(T(v)) is v, thus CEXTI(I(M(T(v))))=EC(v). Finally, from above, I(v)∈IOC.
Base Case: v ∈ VD, including rdfs:Literal
As v∈VD and I satisfies T(V), thus I(v)∈CEXTI(I(rdfs:Datatype)). Because I is an OWL DL interpretation CEXTI(I(v))⊆LVI, so <I(v),I(rdfs:Literal)>∈EXTI(I(rdfs:subClassOf)). Thus I RDF-compatibile satisfies T(v). As M(T(v)) is v, thus CEXTI(I(M(T(v))))=EC(v). Finally, from above I(v)∈IDC.
Base Case: d=oneOf(i1…in), where the ij are individual IDs
As ij∈VI for 1≤j≤n and I satisfies T(V), thus I(ij)∈IOT. The second comprehension principle for sequences then requires that there is some l∈IL that is a sequence of I(i1),…,I(in) over IOT. For any l that is a sequence of I(i1),…,I(in) over IOT the comprehension principle for oneOf requires that there is some y∈CEXTI(I(rdfs:Class)) such that <y,l> ∈ EXTI(IS(owl:oneOf)). From the third characterization of oneOf, y∈IOC. Therefore I satisfies T(d). For any I+A that satisfies T(d), CEXTI(I+A(M(T(d)))) = {I(i1),…,I(in)} = EC(d). Finally, I+A(M(T(d)))∈IOC.
Base Case: d=oneOf(v1…vn), where the vi are data literals
Because I(vj)∈LVI, the second comprehension principle for sequences then requires that there is some l∈IL that is a sequence of I(v1),…,I(vn) over LVI. For any l that is a sequence of I(v1),…,I(vn) over LVI the comprehension principle for oneOf requires that there is some y∈CEXTI(I(rdfs:Class)) such that <y,l> ∈ EXTI(IS(owl:oneOf)). From the second characterization of oneOf, y∈IOC. Therefore I satisfies T(d). For any I+A that satisfies T(d), CEXTI(I+A(M(T(d)))) = {I(i1),…,I(in)} = EC(d). Finally, I+A(M(T(d)))∈IDC.
Base Case: d=restriction(p value(i)), with p∈VOP∪VDP and i an individualID
As p∈VOP∪VDP, from above I satisfies T(p). As I satisfies T(V'), I(p)∈IOOP∪IODP. As i∈VI and I satisfies T(V'), I(i)∈IOT. From a comprehension principle for restriction, I satisfies T(d). For any A such that I+A satisfies T(d), CEXTI(I+A(M(T(d)))) = { x∈IOT | <x,I(i)> ∈ EXTI(p) } = { x∈R | <x,S(i)> ∈ ER(p) } = EC(d). Finally, I+A(M(T(d)))∈IOC.
Base Case: d=restriction(p value(i)), with p∈VOP∪VDP and i a typed data value.
Similar.
Base Case: d=restriction(p minCardinality(n)), with p∈VOP∪VDP and n a non-negative integer
Similar.
Base Case: d=restriction(p maxCardinality(n)), with p∈VOP∪VDP and n a non-negative integer
Similar.
Base Case: d=restriction(p Cardinality(n)), with p∈VOP∪VDP and n a non-negative integer
Similar.
Inductive Case: d=complementOf(d')
From the induction hypothesis, I satisfies T(d'). As d' is a description, from the induction hypothesis there is a mapping, A, that maps all the blank nodes in T(d') into domain elements such that I+A satisfies T(d') and I+A(M(T(d'))) = EC(d') and I+A(M(T(d')))∈IOC. The comprehension principle for complementOf then requires that there is a y∈IOC such that I+A satisfies <y,e>∈EXTI(I(owl:complementOf)) so I satisfies T(d). For any I+A that satisfies T(d), CEXTI(I+A(M(T(d)))) = IOT-CEXTI(I+A(M(T(d)))) = R-EC(d') = EC(d). Finally, I+A(M(T(d)))∈IOC.
Inductive Case: d = unionOf(d1 … dn)
From the induction hypothesis, I satisfies di for 1≤i≤n so there is a mapping, Ai, that maps all the blank nodes in T(di) into domain elements such that I+Ai satisfies T(di). As the blank nodes in T(di) are disjoint from the blank nodes of T(dj) for i≠j, I+A1+…+An, and thus I, satisfies T(di)∪…∪T(dn). Each di is a description, so from the induction hypothesis, I+A1+…+An(M(T(di)))∈IOC. The first comprehension principle for sequences then requires that there is some l∈IL that is a sequence of I+A1+…+An(M(T(d1))),…, I+A1+…+An(M(T(dn))) over IOC. The comprehension principle for unionOf then requires that there is some y∈IOC such that <y,l>∈EXTI(I(owl:unionOf)) so I satisfies T(d).
For any I+A that satisfies T(d), I+A satisfies T(di) so CEXTI(I+A(di)) = EC(di)). Then CEXTI(I+A(M(T(d)))) = CEXTI(I+A(d1))∪…∪CEXTI(I+A(dn)) = EC(d1)∪…∪EC(dn) = EC(d). Finally, I(M(T(d)))∈IOC.
Inductive Case: d = intersectionOf(d1 … dn)
Similar.
Inductive Case: d = restriction(p x1 x2 … xn)
As p∈VOP∪VDP, from above I satisfies T(p). From the induction hypothesis, I satisfies restriction(p xi) for 1≤i≤n so there is a mapping, Ai, that maps all the blank nodes in T(restriction(p xi)) into domain elements such that I+Ai satisfies T(restriction(p xi)). As the blank nodes in T(restriction(p xi)) are disjoint from the blank nodes of T(restriction(p xj)) for i≠j, I+A1+…+An, and thus I, satisfies T(restriction(p x1 … xn)). Each restriction(p xi) is a description, so from the induction hypothesis, M(T(restriction(p xi)))∈IOC. The first comprehension principle for sequences then requires that there is some l∈IL that is a sequence of I+A1+…+An(M(T(restriction(p xi)))),…, I+A1+…+An(M(T(restriction(p xi)))) over IOC. The comprehension principle for intersectionOf then requires that there is some y∈IOC such that <y,l>∈EXTI(I(owl:intersectionOf)) so I satisfies T(d).
For any I+A that satisfies T(d) I+A satisfies T(di) so CEXTI(I+A(di)) = EC(di)). Then CEXTI(I+A(M(T(d)))) = CEXTI(I+A(restriction(p xi)))∩…∩ CEXTI(I+A(restriction(p xn))) = EC(restriction(p xi))cap;…∩EC(restriction(p xi)) = EC(d). Finally, I(M(T(d)))∈IOC.
Inductive Case: d = restriction(p allValuesFrom(d')), with p∈VOP∪VDP and d' a description
As p∈VOP∪VDP, from above I satisfies T(p). From the induction hypothesis, I satisfies T(d'). As d' is a description, from the induction hypothesis, any mapping, A, that maps all the blank nodes in T(d') into domain elements such that I+A satisfies T(d') has I+A(M(T(d'))) = EC(d') and I+A(M(T(d')))∈IOC. As p∈VOP∪VDP and I satisfies T(V'), I(p)∈IOOP∪IODP. The comprehension principle for allValuesFrom restrictions then requires that I satisfies the triples in T(d) that are not in T(d') or T(p) in a way that shows that I satisfies T(d).
For any I+A that satisfies T(d), CEXTI(I+A(M(T(d)))) = {x∈IOT | ∀ y∈IOT : <x,y>∈EXTI(p) implies y∈CEXTI(M(T(d')))} = {x∈R | ∀ y∈R : <x,y>∈ER(p) implies y∈EC(d')} = EC(d). Finally, I+A(M(T(d)))∈IOC.
Inductive Case: d = restriction(p someValuesFrom(d)) with p∈VOP∪VDP and d' a description
Similar.
Inductive Case: d = restriction(p allValuesFrom(d)) with p∈VOP∪VDP and d' a data range
Similar.
Inductive Case: d = restriction(p someValuesFrom(d)) with p∈VOP∪VDP and d' a data range
Similar.

Lemma 1.1: Let V', V, I', and I be as in Lemma 1. Let d be an abstract OWL individual construct over V', (of the form Individual(…)). Then for any A mapping all the blank nodes of T(d) into RI where I+A OWL DL satisfies T(d), I+A(M(T(d))) ∈ EC(d). Also, for any r ∈ EC(d) there is some A mapping all the blank nodes of T(d) into RI such that I+A(M(T(d))) = r.

Proof:

A simple inductive argument shows that I+A(M(T(d))) must satisfy all the requirements of EC(d). Another inductive argument, depending on the non-sharing of blank nodes in sub-constructs, shows that for each r ∈ EC(d) there is some A such that I+A(M(T(d))) = r.

A.1.2 Correspondence for Directives

Lemma 1.9: Let V', V, I', and I be as in Lemma 1. Let F be an OWL directive over V' with an annotation of the form annotation(p x). If F is a class or property axiom, let n be the name of the class or property. If F is an individual axiom, let n be the main node of T(F). Then for any A mapping all the blank nodes of T(F) into RI, I+A OWL DL satisfies the triples resulting from the annotation iff I' direct satisfies the conditions resulting from the annotation.

Proof:

For annotations to URI references, the lemma can be easily established by an inspection of the semantic condition and the translation triples. For annotations to Individual(…), the use of Lemma 1.1 is also needed.

Lemma 2: Let V', V, I', and I be as in Lemma 1. Let F be an OWL directive over V'. Then I satisfies T(F) iff I' satisfies F.

Proof:

The main part of the proof is a structural induction over directives. Annotations occur in many directives and work exactly the same so they just require a use of Lemma 1.9. The rest of the proof will thus ignore annotations. Deprecations can be handled in a similar fashion and will also be ignored in the rest of the proof.

Case: F = Class(foo complete d1 … dn).

Let d=intersectionOf(d1 … dn). As d is a description over V', thus I satisfies T(d) and for any A mapping the blank nodes of T(d) such that I+A satisfies T(d), CEXTI(I+A(M(T(d)))) = EC(d). Thus for any sub-description of d, d', CEXTI(I+A(M(T(d')))) = EC(d'), and I+A(M(T(d')))∈IOC. Thus for some A mapping the blank nodes of T(d) such that I+A satisfies T(d), CEXTI(I+A(M(T(d)))) = EC(d) and I+A(M(T(d)))∈IOC; and for each d' a sub-description of d, CEXTI(I+A(M(T(d')))) = EC(d'), and I+A(M(T(d')))∈IOC.

If I' satisfies F then EC(foo) = EC(d). From above, there is some A such that CEXTI(I+A(M(T(d)))) = EC(d) = EC(foo) = CEXTI(I(foo)) and I+A(M(T(d)))∈IOC. Because I satisfies T(V), I(foo)∈IOC, thus <I(foo),I+A(M(T(d)))> ∈ EXTI(I(owl:equivalentClass)). Further, because of the semantic conditions on I(owl:intersectionOf), <I(foo),I+A(M(T(SEQ d1 … dn)))> ∈ EXTI(I(owl:intersectionOf)).

If d is of the form intersectionOf(d1) then CEXTI(I+A(M(T(d1)))) = EC(d1) = EC(d) = EC(foo) and I+A(M(T(d1)))∈IOC. So, from the semantic conditions on I(owl:equivalentClass), <I(foo),I+A(M(T(d1)))> ∈ EXTI(I(owl:equivalentClass)). If d1 is of the form complementOf(d'1) then IOT - CEXTI(I+A(M(T(d'1)))) = CEXTI(I+A(M(T(d1)))) = EC(d1) = EC(d) = EC(foo) and I+A(M(T(d'1)))∈IOC. So, from the semantic conditions on I(owl:complementOf), <I(foo),I+A(M(T(d'1)))> ∈ EXTI(I(owl:complementOf)). If d1 is of the form unionOf(d11 … d1m) then CEXTI(I+A(M(T(d11)))) ∪ … ∪ CEXTI(I+A(M(T(d1m)))) = CEXTI(I+A(M(T(d1)))) = EC(d1) = EC(d) = EC(foo) and I+A(M(T(d1j)))∈IOC, for 1≤ j ≤ m. So, from the semantic conditions on I(owl:unionOf), <I(foo),I+A(M(T(SEQ d11 … d1m)))> ∈ EXTI(I(owl:unionOf)).

Therefore I satisfies T(F), for each potential T(F).

If I satisfies T(F) then I satisfies T(intersectionOf(d1 … dn)). Thus there is some A as above such that <I(foo),I+A(M(T(d)))> ∈ EXTI(I(owl:equivalentClass)). Thus EC(d) = CEXTI(I+A(M(T(d)))) = CEXTI(I(foo)) = EC(foo). Therefore I' satisfies F.

Case: F = Class(foo partial d1 … dn)

Let d=intersectionOf(d1 … dn). As d is a description over V', thus I satisfies T(d) and for any A mapping the blank nodes of T(d) such that I+A satisfies T(d), CEXTI(I+A(M(T(d)))) = EC(d). Thus CEXTI(I+A(M(T(di)))) = EC(di), for 1 ≤ i ≤ n. Thus for some A mapping the blank nodes of T(d) such that I+A satisfies T(d), CEXTI(I+A(M(T(di)))) = EC(di), and I+A(M(T(di))∈IOC, for 1 ≤ i ≤ n.

If I' satisfies F then EC(foo) ⊆ EC(di), for 1 ≤ i ≤ n. From above, there is some A such that CEXTI(I+A(M(T(di)))) = EC(di) ⊇ EC(foo) = CEXTI(I(foo)) and I+A(M(T(di))∈IOC. Because I satisfies T(V), I(foo)∈IOC, thus <I(foo),I+A(M(T(di)))> ∈ EXTI(I(rdfs:subClassOf)), for 1 ≤ i ≤ n. Therefore I satisfies T(F).

If I satisfies T(F) then I satisfies T(di), for 1 ≤ i ≤ n. Thus there is some A as above such that <I(foo),I+A(M(T(di)))> ∈ EXTI(I(rdfs:subClassOf)), for 1 ≤ i ≤ n. Thus EC(d) = CEXTI(I+A(M(T(di)))) ⊇ CEXTI(I(foo)) = EC(foo), for 1 ≤ i ≤ n. Therefore I' satisfies F.

Case: F = EnumeratedClass(foo i1 … in)

Let d=oneOf(i1 … in). As d is a description over V' so I satisfies T(d) and for some A mapping the blank nodes of T(d) such that I+A satisfies T(d), EC(d) = CEXTI(I+A(M(T(d)))) = {SI(M(T(i1)), … SI(M(T(in))} Also, SI(M(T(ij)) ∈ IOT, for 1 ≤ j ≤ n.

If I' satisfies F then EC(foo) = EC(d). From above, there is some A such that CEXTI(I+A(M(T(d)))) = EC(d) = EC(foo) = CEXTI(I(foo)) and I+A(M(T(d))∈IOC. Let e be I+A(M(T(SEQ i1 … in))). Then, from the semantic conditions on I(owl:oneOf), <I(foo),e> ∈ EXTI(I(owl:oneOf)). Therefore I satisfies T(F).

If I satisfies T(F) then I satisfies T(SEQ i1 … in). Thus there is some A as above such that <I(foo),I+A(M(T(SEQ i1 … in)))> ∈ EXTI(I(owl:oneOf)). Thus {SI(M(T(i1)), …, SI(M(T(in))} = CEXTI(I(foo)) = EC(foo). Therefore I' satisfies F.

Case: F = Datatype(foo)

The only thing that needs to be shown here is the typing for foo, which is similar to that for classes.

Case: F= DisjointClasses(d1 … dn)

As di is a description over V' therefore I satisfies T(di) and for any A mapping the blank nodes of T(di) such that I+A satisfies T(di), CEXTI(I+A(M(T(di)))) = EC(di).

If I satisfies T(F) then for 1≤i≤n there is some Ai such that I satisfies <I+Ai(M(T(di))),I+Aj(M(T(dj)))> ∈ EXTI(I(owl:disjointWith)) for each 1≤i<j≤n. Thus EC(di)∩EC(dj) = {}, for i≠j. Therefore I' satisfies F.

If I' satisfies F then EC(di)∩EC(dj) = {} for i≠j. For any Ai and Aj as above <I+Ai+Aj(M(T(di))),I+Ai+Aj(M(T(dj)))> ∈ EXTI(I(owl:disjointWith)), for i≠j. As at least one Ai exists for each i, and the blank nodes of the T(dj) are all disjoint, I+A1+…+An satisfies T(DisjointClasses(d1 … dn)). Therefore I satisfies T(F).

Case: F = EquivalentClasses(d1 … dn)
Similar.
Case: F = SubClassOf(d1 d2)
Somewhat similar.
Case: F = ObjectProperty(p super(s1) … super(sn) domain(d1) … domain(dm) range(r1) … range(rk) [inverse(i)] [Symmetric] [Functional] [InverseFunctional] [OneToOne] [Transitive])

As di for 1≤i≤m is a description over V' therefore I satisfies T(di) and for any A mapping the blank nodes of T(di) such that I+A satisfies T(di), CEXTI(I+A(M(T(di)))) = EC(di). Similarly for ri for 1≤i≤k.

If I' satisfies F, then, as p∈VOP, I satisfies I(p)∈IOOP. Then, as I is an OWL DL interpretation, I satisfies <I(p),I(owl:Thing)>∈EXTI(I(rdfs:domain)) and <I(p),I(owl:Thing)>∈EXTI(I(rdfs:range)). Also, ER(p)⊆ER(si) for 1≤i≤n, so EXTI(I(p))=ER(p) ⊆ ER(si)=EXTI(I(si)) and I satisfies <I(p),I(si)>∈EXTI(I(rdfs:subPropertyOf)). Next, ER(p)⊆EC(di)×R for 1≤i≤m, so <z,w>∈ER(p) implies z∈EC(di) and for any A such that I+A satisfies T(di), <z,w>∈EXTI(p) implies z∈CEXTI(I+A(M(T(di)))) and thus <I(p),I+A(M(T(di)))>∈EXTI(I(rdfs:domain)). Similarly for ri for 1≤i≤k.

If I' satisfies F and inverse(i) is in F, then ER(p) and ER(i) are converses. Thus <u,v>∈ER(p) iff <v,u>∈ER(i) so <u,v>∈EXTI(p) iff <v,u>∈EXTI(i) and I satisfies <I(p),I(i)>∈EXTI(I(owl:inverseOf)). If I' satisfies F and Symmetric is in F, then ER(p) is symmetric. Thus if <x,y>∈ ER(p) then <y,x>∈ER(p) so if <x,y> ∈ EXTI(p) then <y, x>∈EXTI(p). and thus I satisfies p∈CEXTI(I(owl:Symmetric)). Similarly for Functional, InverseFunctional, and Transitive. Thus if I' satisfies F then I satisfies T(F).

If I satisfies T(F) then, for 1≤i≤n, <I(p),I(si)>∈EXTI(I(rdfs:subPropertyOf)) so ER(p)=EXTI(I(p)) ⊆ EXTI(I(si))=ER(si). Also, for 1≤i≤m, for some A such that I+A satisfies T(di), <I(p),I+A(M(T(di)))>∈EXTI(I(rdfs:domain)) so <z,w>∈EXTI(p) implies z∈CEXTI(I+A(M(T(di)))). Thus <z,w>∈ER(p) implies z∈EC(di) and ER(p)⊆EC(di)×R. Similarly for ri for 1≤i≤k.

If I satisfies T(F) and inverse(i) is in F, then I satisfies <I(p),I(i)>∈EXTI(I(owl:inverseOf)). Thus <u,v>∈EXTI(p) iff <v,u>∈EXTI(i) so <u,v>∈ER(p) iff <v,u>∈ER(i) and ER(p) and ER(i) are converses. If I satisfies F and Symmetric is in F, then I satisfies p∈CEXTI(I(owl:Symmetric)) so if <x,y> ∈ EXTI(p) then <y, x>∈EXTI(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(F) then I' satisfies F.

Case: F = DatatypeProperty(p super(s1) … super(sn) domain(d1) … domain(dm) range(r1) … range(rl) [Functional])
Similar, but simpler.
Case: F = AnnotationProperty(p domain(d1) … domain(dm))
Similar, but even simpler.
Case: F = OntologyProperty(p domain(d1) … domain(dm))
Similar, but even simpler.
Case: F = EquivalentProperties(p1 … pn), for pi∈VOP

As pi∈VOP and I satisfies T(V'), I(pi)∈IOOP. If I satisfies T(F) then <I(pi),I(pj)> ∈ EXTI(I(owl:equivalentProperty)), for each 1≤i<j≤n. Therefore EXTI(pi) = EXTI(pj), for each 1≤i<j≤n; ER(pi) = ER(pj), for each 1≤i<j≤n; and I' satisfies F.

If I' satisfies F then ER(pi) = ER(pj), for each 1≤i<j≤n. Therefore EXTI(pi) = EXTI(pj), for each 1≤i<j≤n. From the OWL DL definition of owl:equivalentProperty, <I(pi),I(pj)> ∈ EXTI(I(owl:equivalentProperty)), for each 1≤i<j≤n. Thus I satisfies T(F).

Case: F = SubPropertyOf(p1 p2)
Somewhat similar, but simpler.
Case: F = SameIndividual(i1 … in)
Similar to SamePropertyAs.
Case: F = DifferentIndividuals(i1 … in)
Similar to SamePropertyAs.
Case: F = Individual([i] type(t1) … type(tn) value(p1 v1) … value(pn vn))

If I satisfies T(F) then there is some A that maps each blank node in T(F) such that I+A satisfies T(F). A simple examination of T(F) shows that the mappings of A plus the mappings for the individual IDs in F, which are all in IOT, show that I' satisfies F.

If I' satisfies F then for each Individual construct in F there must be some element of R that makes the type relationships and relationships true in F. The triples in T(F) 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(F).

A.1.3 From RDF Semantics to Direct Semantics

Lemma 3: Let V' = VO + VC + VD + VI + VOP + VDP + VAP + VXP be a separated OWL vocabulary. Let V = VO ∪ VC ∪ VD ∪ VI ∪ VOP ∪ VDP ∪ VAP ∪ VXP ∪ VB. Then for every OWL DL interpretation I = <RI,PI,EXTI,SI,LI,LVI> of V that satisfies T(V') there is an direct interpretation I' of V' such that for any collection of OWL abstract ontologies and axioms and facts O with vocabulary V' such that O is imports closed, I' direct satisfies O iff I OWL DL satisfies T(O).

Proof:

Let CEXTI be defined as usual from I. The required direct interpretation will be I' = < RI, EC, ER, L, S, LVI > where

  1. EC(v) = CEXTI(SI(v)), for v∈VC∪VD
  2. ER(v) = EXTI(SI(v)), for v∈VOP∪VDP∪VAP∪VXP
  3. < x, S(owl:DeprecatedClass) > ∈ ER(rdf:type) iff < x, SI(owl:DeprecatedClass) > EXTI(SI(rdf:type)), for x ∈ R
  4. < x, S(owl:DeprecatedProperty) > ∈ ER(rdf:type) iff < x, SI(owl:DeprecatedProperty) > EXTI(SI(rdf:type)), for x ∈ R
  5. L(d) = LI(d), for d a typed literal
  6. S(v) = SI(v), for n∈VI ∪ VC ∪ VD ∪ VOP ∪ VDP ∪ VAP ∪ VXP ∪ VO

V', V, I', and I meet the requirements of Lemma 2, so for any directive D over V' I satisfies T(D) iff I' satisfies D.

Because O is imports closed, O includes all the ontologies that would be imported in T(O) so the importing part of imports directives will be handled the same. Satisfying an abstract ontology is just satisfying its directives and satisfying the translation of an abstract ontology is just satisfying all the triples so I OWL DL satisfies T(K) iff I' direct satisfies K.

A.1.4 From Direct Semantics to RDF Semantics

Lemma 4: Let V' = VO + VC + VD + VI + VOP + VDP + VAP + VXP be a separated OWL vocabulary. Let V = VO ∪ VC ∪ VD ∪ VI ∪ VOP ∪ VDP ∪ VAP ∪ VXP ∪ VB. Then for every direct interpretation I' = < U, EC, ER, L, S, LV > of V' there is an OWL DL interpretation I of V that satisfies T(V') such that for any collection of OWL abstract ontologies and axioms and facts O with vocabulary V' such that O is imports closed, I' direct satisfies O iff I OWL DL satisfies T(O).

Proof:

Construct I = < RI, PI, EXTI, SI, L, LVI > as follows:

Then I is an OWL DL interpretation because the conditions for the class extensions in OWL DL match up with the conditions for class-like OWL abstract syntax constructs.

V', V, I', and I meet the requirements of Lemma 2, so for any directive D over V' I satisfies T(D) iff I' satisfies D.

Because O is imports closed, O includes all the ontologies that would be imported in T(O) the importing part of imports directives will be handled the same. Satisfying an abstract ontology is just satisfying its directives and satisfying the translation of an abstract ontology is just satisfying all the triples so I OWL DL satisfies T(K) iff I' direct satisfies K.

A.1.5 Correspondence Theorem

Theorem 1: Let O and O' be collections of OWL DL ontologies and axioms and facts in abstract syntax form that are imports closed, such that their union has a separated vocabulary, V', and every URI reference in V' is used in O. Then O entails O' if and only if T(O) OWL DL entails T(O').

Then I satisfies T(V'), because each URI reference in V' is used on O.

Proof: Suppose O entails O'. Let I be an OWL DL interpretation that satisfies T(O). Then from Lemma 3, there is some direct interpretation I' such that for any abstract OWL ontology or axiom or fact X over V', I satisfies T(X) iff I' satisfies X. Thus I' satisfies each ontology in O. Because O entails O', I' satisfies O', so I satisfies T(O'). Thus T(K),T(V') OWL DL entails T(Q).

Suppose T(O) OWL DL entails T(O'). Let I' be an direct interpretation that satisfies K. Then from Lemma 4, there is some OWL DL interpretation I such that for any abstract OWL ontology X over V', I satisfies T(X) iff I' satisfies X. Thus I satisfies T(O). Because T(O) OWL DL entails T(O'), I satisfies T(O'), so I' satisfies O'. Thus O entails O'.

A.2 Correspondence between OWL DL and OWL Full

This section contains a proof 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 an RDF graph. An OWL interpretation of K is an OWL interpretation (from Section 5.2) that is an D-interpretation of K.

Lemma 5: Let V be a separated vocabulary. Then for every OWL intepretation I there is an OWL DL interpretation I' (as in Section 5.3) such that for K any OWL ontology in the abstract syntax with separated vocabulary V, I is an OWL interpretation of T(K) iff I' is an OWL DL interpretation of T(K).

Proof sketch: As all OWL DL interpretations are OWL interpretations, the reverse direction is obvious.

Let I = < RI, EXTI, SI, LI > be an OWL interpretation that satisfies T(K). Let I' = < RI', EXTI', SI', LI' > be an OWL interpretation that satisfies T(K). Let RI' = CEXTI(I(owl:Thing)) + CEXTI(I(owl:ObjectProperty)) + CEXTI(I(owl:ObjectProperty)) + CEXTI(I(owl:Class)) + CEXTI(I(rdf:List)) + RI, where + is disjoint union. Define EXTI' so as to separate the various roles of the copies. Define SI' so as to map vocabulary into the appropriate copy. This works because K has a separated vocabulary, so I can be split according the the roles, and there are no inappropriate relationships in EXTI. In essence the first component of RI' is OWL individuals, the second component of RI' is OWL datatype properties, the third component of RI' is OWL individual-valued properties, the fourth component of RI' is OWL classes, the fifth component of RI' is RDF lists, and the sixth component of RI' is everything else.

Theorem 2: Let O and O' be collections of OWL DL ontologies and axioms and facts in abstract syntax form that are imports closed, such that their union has a separated vocabulary (Section 4.2). Then the translation of O OWL Full entails the translation of O' if the translation of O OWL DL entails the translation of O'.

Proof: From the above lemma and because all OWL Full interpretations are OWL interpretations.

Note: The only if direction is not true.


Appendix B. Examples (Informative)

This appendix gives examples of the concepts developed in the rest of the document.

B.1 Examples of Mapping from Abstract Syntax to RDF Graphs

The transformation rules in Section 4 can transform the ontology

Ontology(ex:ontology
  DatatypeProperty(ex:name)
  ObjectProperty(ex:author)
  Class(ex:Book)
  Class(ex:Person)

  Individual(type(ex:Book) 
        value(ex:author Individual(type(ex:Person) value(ex:name "Fred"^^xsd:string)))))

to

  ex:ontology rdf:type owl:Ontology .
  ex:name rdf:type owl:DatatypeProperty .
  ex:author rdf:type owl:ObjectProperty .
  ex:Book rdf:type owl:Class .
  ex:Person rdf:type owl:Class .

  _:x rdf:type ex:Book .
  _:x ex:author _:x1 .
  _:x1 rdf:type ex:Person .
  _:x1 ex:name "Fred"^^xsd:string .

and

Ontology(ex:ontology2
  Class(ex:Person)
  Class(ex:Student)
  ObjectProperty(ex:enrolledIn)
  Class(ex:Student complete ex:Person
                   restriction(ex:enrolledIn allValuesFrom(ex:School) minCardinality(1))))

can be transformed to

  ex:ontology2 rdf:type owl:Ontology .
  ex:enrolledIn rdf:type owl:ObjectProperty .
  ex:Person rdf:type owl:Class .
  ex:School rdf:type owl:Class .

  ex:Student rdf:type owl:Class .
  ex:Student owl:equivalentClass _:x .

  _:x owl:intersectionOf _:l1 .
  _:l1 rdf:first  ex:Person .
  _:l1 rdf:rest _:l2 .
  _:l2 rdf:first  _:lr .
  _:l2 rdf:rest rdf:nil .

  _:lr owl:intersectionOf _:lr1 .
  _:lr1 rdf:first _:r1 .
  _:lr1 rdf:rest _:lr2 .
  _: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 "1"^^xsd:nonNegativeInteger .

B.2 Examples of Entailments in OWL DL and OWL Full

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 .

The above three triples would have to be added before the following restriction could be concluded

John rdf:type _:x .
_:x owl:onProperty friend .
_:x owl:minCardinality "1"^^xsd:nonNegativeInteger .

However, once this extra information is 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"^^xsd:nonNegativeInteger .

does not entail

John rdf:type _:y .
_: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 separated-syntax 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"^^xsd:nonNegativeInteger .


Appendix C. Changes from Last Call (Informative)

This appendix provides an informative account of the changes from the last-call version of this document. All substantive post-last call changes to the document, as well as some editorial post-last-call changes, are indicated in the style of this appendix.

C.1 Substantive changes after Last Call

This section provides information on the post Last Call changes to the document that make changes to the specification of OWL.

C.2 Editorial changes after Last Call

This section provides information on post Last Call editorial changes to the document, i.e., changes that do not affect the specification of OWL.

C.3 Substantive changes after Candidate RecommentationRecommendation

This section provides information on the post Candidate Recommendation changes to the document that make changes to the specification of OWL.

C.4 Editorial changes after Candidate RecommentationRecommendation

This section provides information on post Candidate RecommentationRecommendation editorial changes to the document, i.e., changes that do not affect the specification of OWL.

C.5 Changes since Proposed Recommendation

This section provides information on post Proposed Recommendation changes to the document.


Index of Vocabulary (Informative)

The following table provides pointers to information about each element of the OWL vocabulary, as well as some elements of the RDF and RDFS vocabularies. The first column points to the vocabulary element's major definition in the abstract syntax of Section 2. The second column points to the vocabulary element's major definition in the OWL Lite abstract syntax. The third column points to the vocabularly element's major definition in the direct semantics of Section 3. The fourth column points to the major piece of the translation from the abstract syntax to triples for the vocabulary element Section 4. The fifth column points to the vocabularly element's major definition in the RDFS-compatible semantics of Section 5.

Vocabulary Terms
Vocabulary Term Abstract OWL DL Syntax Abstract OWL Lite Syntax Direct Semantics Mapping to Triples RDFS-Compatible Semantics
owl:AllDifferent 4.1 5.2
owl:allValuesFrom 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:AnnotationProperty 2.3.1.3 2.3.2.4 3.2 4.1 5.2
owl:backwardCompatibleWith 2.1 2.1 4.1
owl:cardinality 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:Class 2.3.2.1 2.3.1.1 3.3 4.1 5.2
owl:complementOf 2.3.2.2 3.2 4.1 5.2
owl:DatatypeProperty 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:DeprecatedClass 2.3.2.1 2.3.1.1 3.3 4.1 5.2
owl:DeprecatedProperty 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:DataRange 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:differentFrom 2.2 2.2 3.3 4.1 5.2
owl:disjointWith 2.3.2.1 3.3 4.1 5.2
owl:distinctMembers 4.1 5.2
owl:equivalentClass 2.3.2.1 2.3.1.1 3.3 4.1 5.2
owl:equivalentProperty 2.3.1.3 2.3.1.3 3.3 4.1 5.2
owl:FunctionalProperty 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:hasValue 2.3.2.3 3.2 4.1 5.2
owl:imports 2.1 2.1 3.4 4.1 5.4
owl:incompatibleWith 2.1 2.1 4.1
owl:intersectionOf 2.3.2.2 3.2 4.1 5.2
owl:InverseFunctionalProperty 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:inverseOf 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:maxCardinality 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:minCardinality 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:Nothing 2.1 2.1 3.2 4.1 5.2
owl:ObjectProperty 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:oneOf 2.3.2.2 3.2 4.1 5.2
owl:onProperty 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:Ontology 2.1 2.1 3.4 4.1 5.2
owl:OntologyProperty 2.3.1.3 2.3.2.4 3.2 4.1 5.2
owl:priorVersion 2.1 2.1 4.1
owl:Restriction 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:sameAs 2.2 2.2 3.3 4.1 5.2
owl:someValuesFrom 2.3.2.3 2.3.1.2 3.2 4.1 5.2
owl:SymmetricProperty 2.3.2.4 2.3.1.3 3.3 4.1 4.2
owl:Thing 2.1 2.1 3.2 4.1 5.2
owl:TransitiveProperty 2.3.2.4 2.3.1.3 3.3 4.1 5.2
owl:unionOf 2.3.2.2 3.2 4.1 5.2
owl:versionInfo 2.1 2.1 4.1
rdf:List 4.1 5.2
rdf:nil 4.1 5.2
rdf:type 2.2 2.2 3.3 4.1
rdfs:comment 2.1 2.1 4.1
rdfs:Datatype 4.1 5.2
rdfs:domain 2.3.2.4 2.3.1.3 3.3 4.1 5.2
rdfs:label 2.1 2.1 4.1
rdfs:Literal 2.3.1.3 2.3.2.3 4.1 4.1 5.2
rdfs:range 2.3.2.4 2.3.1.3 3.3 4.1 5.2
rdfs:subClassOf 2.3.2.1 2.3.1.1 3.3 4.1 5.2
rdfs:subPropertyOf 2.3.1.3 2.3.1.3 3.3 4.1 5.2

Acknowledgments

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 DAML+OIL and thus in OWL are also present in the Ontology Inference Layer (OIL).

This document is the result of extensive discussions within the Web Ontology Working Group as a whole. The participants in this working group included: Yasser al Safadi, Jean-FrancoisalSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, JeromeJérôme Euzenat, Dieter Fensel,Tim Finin, Nicholas Gibbins, PatSandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Mario Jeckle, RuedigerRüdiger Klein, Natasha Kravtsova, Ora Lassila, Alexander Maedche,Massimo Marchiori, Deborah McGuinness, Libby Miller,Enrico Motta, Leo Obrst, Laurent Olivry , Peter Patel-Schneider,Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Shimizu Noboru,Noboru Shimizu, Michael Sintek, Michael Smith, NedK. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, Lynne R. Thompson,David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, and John Yanosy.


References

Normative References

[RDF Concepts]
Resource Description Framework (RDF): Concepts and Abstract Syntax ., Graham Klyne and Jeremy J. Carroll, eds.Editors, W3C Working Draft 05 September 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/RDFCore/TR/staging/rdf-concepts/ . Latest version isavailable at http://www.w3.org/TR/rdf-concepts/ .
http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/ . -->[RDF MT]Semantics]
RDF Semantics ., Patrick Hayes, ed.Editor, W3C Working Draft 05 September 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/RDFCore/TR/staging/rdf-mt/ . Latest version isavailable at http://www.w3.org/TR/rdf-mt/ .
http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/ . -->[RDF Syntax]
RDF/XML Syntax Specification (Revised), Dave Beckett, ed.Editor, W3C Working Draft 05 September 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/RDFCore/TR/staging/rdf-syntax-grammar/ . Latest version isavailable at http://www.w3.org/TR/rdf-syntax-grammar/ .
[RDF Tests]
RDF Test Cases ., Jan Grant and Dave Beckett, eds.Editors, W3C Working Draft 05 September 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/RDFCore/TR/staging/rdf-testcases/ . Latest version isavailable at http://www.w3.org/TR/rdf-testcases/ .
http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-testcases-20030117/ . -->[XML]
Extensible Markup Language (XML) 1.0 (Second Edition). Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, and Eve Maler, eds. W3C Recommendation 6 October 2000. Latest version is available at http://www.w3.org/TR/REC-xml.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes.. Paul V. Biron and Ashok Malhotra, eds. W3C Recommendation 02 May 2000.2001. Latest version is available at http://www.w3.org/TR/xmlschema-2/.

Other References

[DAML+OIL]
DAML+OIL (March 2001) Reference Description. Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Note 18 December 2001. Latest version is available at http://www.w3.org/TR/daml+oil-reference.
[OWL Guide]
OWL Web Ontology Language Guide ., Michael K. Smith, andChris Welty, and Deborah L. McGuinness.McGuinness, Editors, W3C Candidate Recommendation 18 August 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/WebOnt/TR/STAGE-owl-guide/ . Latest version isavailable at http://www.w3.org/TR/owl-guide/ .
[OWL Issues]
Web Ontology Issue Status. Michael K. Smith, ed. 27 June 2003.
[OWL Overview]
OWL Web Ontology Language Overview ., Deborah L. McGuinness and Frank van Harmelen.Harmelen, Editors, W3C Candidate Recommendation 18 August 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/WebOnt/TR/STAGE-owl-features/ . Latest version isavailable at http://www.w3.org/TR/owl-features/ .
[OWL Reference]
OWL Web Ontology Language Reference ., Mike Dean,Dean and Guus Schreiber, Sean Bechhofer, Frank van Harmelen, Jim Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein.Editors, W3C Candidate Recommendation 18 August 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/WebOnt/TR/STAGE-owl-ref/ . Latest version isavailable at http://www.w3.org/TR/owl-ref/ .
[RDFMS] Resource Description Framework (RDF) Model and[RDF Syntax]
RDF/XML Syntax Specification . Ora Lassila and Ralph R. Swick, eds.(Revised), Dave Beckett, Editor, W3C Recommendation 22Recommendation, 10 February 1999.2004, http://www.w3.org/2001/sw/RDFCore/TR/staging/rdf-syntax-grammar/ . Latest version isavailable at http://www.w3.org/TR/REC-rdf-syntax/http://www.w3.org/TR/rdf-syntax-grammar/ .
[RDF Schema]Vocabulary]
RDF Vocabulary Description Language 1.0: RDF Schema ., Dan Brickley and R. V. Guha, eds.Editors, W3C Working Draft 23 January 2003.Recommendation, 10 February 2004, http://www.w3.org/2001/sw/RDFCore/TR/staging/rdf-schema/ . Latest version isavailable at http://www.w3.org/TR/rdf-schema/ .