OWL Web Ontology Language Semantics and Abstract Syntax

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.

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 Semantics] 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 name	Namespace
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs	http://www.w3.org/2000/01/rdf-schema#
xsd	http://www.w3.org/2001/XMLSchema#
owl	http://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.

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.

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.

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.

2.2. Facts

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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 V_OP will be the URI references for the built-in OWL ontology properties.

Definition: An OWL vocabulary V consists of a set of literals V_L and seven sets of URI references, V_C, V_D, V_I, V_DP, V_IP, V_AP, and V_O. In any vocabulary V_C and V_D are disjoint and V_DP, V_IP, V_AP, and V_OP are pairwise disjoint. V_C, the class names of a vocabulary, contains owl:Thing and owl:Nothing. V_D, the datatype names of a vocabulary, contains the URI references for the built-in OWL datatypes and rdfs:Literal. V_AP, the annotation property names of a vocabulary, contains owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, and rdfs:isDefinedBy. V_IP, the individual-valued property names of a vocabulary, V_DP, the data-valued property names of a vocabulary, and V_I, the individual names of a vocabulary, V_O, the ontology names of a vocabulary, do not have any required members.

Definition: Let D be a datatype map. An Abstract OWL interpretation with respect to D with vocabulary V_L, V_C, V_D, V_I, V_DP, V_IP, V_AP, V_O is a tuple of the form: I = <R, EC, ER, L, S, LV> where (with P being the power set operator)

S is extended to plain literals in V_L 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 Syntax	Interpretation (value of EC)
complementOf(c)	O - EC(c)
unionOf(c₁ … c_n)	EC(c₁) ∪ … ∪ EC(c_n)
intersectionOf(c₁ … c_n)	EC(c₁) ∩ … ∩ EC(c_n)
oneOf(i₁ … i_n), for i_j individual IDs	{S(i₁), …, S(i_n)}
oneOf(v₁ … v_n), for v_j literals	{S(v₁), …, S(v_n)}
restriction(p x₁ … x_n), for n > 1	EC(restriction(p x₁)) ∩…∩EC(restriction(p x_n))
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(p₁ o₁) … annotation(p_k o_k) type(c₁) … type(c_m) pv₁ … pv_n)	EC(annotation(p₁ o₁)) ∩ … EC(annotation(p_k o_k)) ∩ EC(c₁) ∩ … ∩ EC(c_m) ∩ EC(pv₁) ∩…∩ EC(pv_n)
Individual(i annotation(p₁ o₁) … annotation(p_k o_k) type(c₁) … type(c_m) pv₁ … pv_n)	{S(i)} ∩ EC(annotation(p₁ o₁)) ∩ … EC(annotation(p_k o_k)) ∩ EC(c₁) ∩ … ∩ EC(c_m) ∩ EC(pv₁) ∩…∩ EC(pv_n)
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
Directive	Conditions on interpretations
Class(c [Deprecated] complete annotation(p₁ o₁) … annotation(p_k o_k) descr₁ … descr_n)	[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p₁ o₁)) … S(c) ∈ EC(annotation(p_k o_k)) EC(c) = EC(descr₁) ∩…∩ EC(descr_n)
Class(c [Deprecated] partial annotation(p₁ o₁) … annotation(p_k o_k) descr₁ … descr_n)	[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p₁ o₁)) … S(c) ∈ EC(annotation(p_k o_k)) EC(c) ⊆ EC(descr₁) ∩…∩ EC(descr_n)
EnumeratedClass(c [Deprecated] annotation(p₁ o₁) … annotation(p_k o_k) i₁ … i_n)	[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p₁ o₁)) … S(c) ∈ EC(annotation(p_k o_k)) EC(c) = { S(i₁), …, S(i_n) }
Datatype(c [Deprecated] annotation(p₁ o₁) … annotation(p_k o_k) )	[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p₁ o₁)) … S(c) ∈ EC(annotation(p_k o_k)) EC(c) ⊆ LV
DisjointClasses(d₁ … d_n)	EC(d_i) ∩ EC(d_j) = { } for 1 ≤ i < j ≤ n
EquivalentClasses(d₁ … d_n)	EC(d_i) = EC(d_j) for 1 ≤ i < j ≤ n
SubClassOf(d₁ d₂)	EC(d₁) ⊆ EC(d₂)
DatatypeProperty(p [Deprecated] annotation(p₁ o₁) … annotation(p_k o_k) super(s₁) … super(s_n) domain(d₁) … domain(d_n) range(r₁) … range(r_n) [Functional])	[ <S(c),S(owl:DeprecatedProperty)> ∈ ER(rdf:type) ] S(p) ∈ EC(annotation(p₁ o₁)) … S(p) ∈ EC(annotation(p_k o_k)) ER(p) ⊆ O×LV ∩ ER(s₁) ∩…∩ ER(s_n) ∩ EC(d₁)×LV ∩…∩ EC(d_n)×LV ∩ O×EC(r₁) ∩…∩ O×EC(r_n) [ER(p) is functional]
ObjectProperty(p [Deprecated] annotation(p₁ o₁) … annotation(p_k o_k) super(s₁) … super(s_n) domain(d₁) … domain(d_n) range(r₁) … range(r_n) [inverse(i)] [Symmetric] [Functional] [ InverseFunctional] [Transitive])	[ <S(c),S(owl:DeprecatedProperty)> ∈ ER(rdf:type)] S(p) ∈ EC(annotation(p₁ o₁)) … S(p) ∈ EC(annotation(p_k o_k)) ER(p) ⊆ O×O ∩ ER(s₁) ∩…∩ ER(s_n) ∩ EC(d₁)×O ∩…∩ EC(d_n)×O ∩ O×EC(r₁) ∩…∩ O×EC(r_n) [ER(p) is the inverse of ER(i)] [ER(p) is symmetric] [ER(p) is functional] [ER(p) is inverse functional] [ER(p) is transitive]
AnnotationProperty(p annotation(p₁ o₁) … annotation(p_k o_k))	S(p) ∈ EC(annotation(p₁ o₁)) … S(p) ∈ EC(annotation(p_k o_k))
OntologyProperty(p annotation(p₁ o₁) … annotation(p_k o_k))	S(p) ∈ EC(annotation(p₁ o₁)) … S(p) ∈ EC(annotation(p_k o_k))
EquivalentProperties(p₁ … p_n)	ER(p_i) = ER(p_j) for 1 ≤ i < j ≤ n
SubPropertyOf(p₁ p₂)	ER(p₁) ⊆ ER(p₂)
SameIndividual(i₁ … i_n)	S(i_j) = S(i_k) for 1 ≤ j < k ≤ n
DifferentIndividuals(i₁ … i_n)	S(i_j) ≠ S(i_k) for 1 ≤ j < k ≤ n
Individual([i] annotation(p₁ o₁) … annotation(p_k o_k) type(c₁) … type(c_m) pv₁ … pv_n)	EC(Individual([i] annotation(p₁ o₁) … annotation(p_k o_k) type(c₁) … type(c_m) pv₁ … pv_n)) is nonempty

3.4. Interpreting Ontologies

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 Semantics]. 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 description₁ … description_n, 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.

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.

Transformation to Triples
Abstract Syntax (and sequences) - S	Transformation - T(S)	Main Node - M(T(S))
Ontology(O directive₁ … directive_n)	O rdf:type owl:Ontology . T(directive₁) … T(directive_n)
Ontology(directive₁ … directive_n)	O rdf:type owl:Ontology . T(directive₁) … T(directive_n)
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 annotation₁ … annotation_m type(type₁)… type(type_n) value(pID₁ v₁) … value(pID_k v_k))	iID T(annotation₁) … iID T(annotation_m) iID rdf:type T(type₁) . … iID rdf:type T(type_n) . iID T(pID₁) T(v₁) . … iID T(pID_k) T(v_k) .	iID
Individual(annotation₁ … annotation_m type(type₁)…type(type_n) value(pID₁ v₁) … value(pID_k v_k)) (With at least one type.)	_:x T(annotation₁) … _:x T(annotation_m) _:x rdf:type T(type₁) . … _:x rdf:type T(type_n) . _:x T(pID₁) T(v₁) . … _:x T(pID_k) T(v_k) .	_:x
Individual(annotation₁ … annotation_m value(pID₁ v₁) … value(pID_k v_k))	_:x T(annotation₁) … _:x T(annotation_m) _:x rdf:type owl:Thing . _:x T(pID₁) T(v₁) . … _:x T(pID_k) T(v_k) .	_:x
SameIndividual(iID₁ … iID_n)	iID_i owl:sameAs iID_i+1 . 1≤i<n iID_i owl:sameAs iID_j . [opt] 1≤i≠j≤n
DifferentIndividuals(iID₁ … iID_n)	iID_i owl:differentFrom iID_j . OR iID_j owl:differentFrom iID_i . 1≤i<j≤n iID_j owl:differentFrom iID_i . [opt] 1≤i≠j≤n
DifferentIndividuals(iID₁ … iID_n)	_:x rdf:type owl:AllDifferent . _:x owl:distinctMembers T(SEQ iID₁ … iID_n) .
Class(classID [Deprecated] partial annotation₁ … annotation_m description₁ … description_n)	classID rdf:type owl:Class . classID rdf:type rdfs:Class . [opt] [classID rdf:type owl:DeprecatedClass .] classID T(annotation₁) … classID T(annotation_m) classID rdfs:subClassOf T(description₁) . … classID rdfs:subClassOf T(description_n) .
Class(classID [Deprecated] complete annotation₁ … annotation_m description₁ … description_n)	classID rdf:type owl:Class . classID rdf:type rdfs:Class . [opt] [classID rdf:type owl:DeprecatedClass .] classID T(annotation₁) … classID T(annotation_m) classID owl:intersectionOf T(SEQ description₁…description_n) .
Class(classID [Deprecated] complete annotation₁ … annotation_m description)	classID rdf:type owl:Class . classID rdf:type rdfs:Class . [opt] [classID rdf:type owl:DeprecatedClass .] classID T(annotation₁) … classID T(annotation_m) classID owl:equivalentClass T(description) .
Class(classID [Deprecated] complete annotation₁ … annotation_m unionOf(description₁ … description_n))	classID rdf:type owl:Class . classID rdf:type rdfs:Class . [opt] [classID rdf:type owl:DeprecatedClass .] classID T(annotation₁) … classID T(annotation_m) classID owl:unionOf T(SEQ description₁…description_n) .
Class(classID [Deprecated] complete annotation₁ … annotation_m complementOf(description))	classID rdf:type owl:Class . classID rdf:type rdfs:Class . [opt] [classID rdf:type owl:DeprecatedClass .] classID T(annotation₁) … classID T(annotation_m) classID owl:complementOf T(description) .
EnumeratedClass(classID [Deprecated] annotation₁ … annotation_m iID₁ … iID_n)	classID rdf:type owl:Class . classID rdf:type rdfs:Class . [opt] [classID rdf:type owl:DeprecatedClass .] classID T(annotation₁) … classID T(annotation_m) . classID owl:oneOf T(SEQ iID₁…iID_n) .
DisjointClasses(description₁ … description_n)	T(description_i) owl:disjointWith T(description_j) . OR T(description_j) owl:disjointWith T(description_i) . 1≤i<j≤n T(description_i) owl:disjointWith T(description_j) . [opt] 1≤i≠j≤n
EquivalentClasses(description₁ … description_n)	T(description_i) owl:equivalentClass T(description_j) . 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(description₁ description₂)	T(description₁) rdfs:subClassOf T(description₂) .
Datatype(datatypeID [Deprecated] annotation₁ … annotation_m )	datatypeID rdf:type rdfs:Datatype . datatypeID rdf:type rdfs:Class . [opt] [datatypeID rdf:type owl:DeprecatedClass .] datatypeID T(annotation₁) … datatypeID T(annotation_m)
unionOf(description₁ … description_n)	_:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x owl:unionOf T(SEQ description₁…description_n) .	_:x
intersectionOf(description₁ … description_n)	_:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x owl:intersectionOf T(SEQ description₁…description_n) .	_:x
complementOf(description)	_:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x owl:complementOf T(description) .	_:x
oneOf(iID₁ … iID_n)	_:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x owl:oneOf T(SEQ iID₁…iID_n) .	_:x
oneOf(v₁ … v_n)	_:x rdf:type owl:DataRange . _:x rdf:type rdfs:Class . [opt] _:x owl:oneOf T(SEQ v₁ … v_n) .	_:x
restriction(ID component₁ … component_n) (With at least two components)	_:x rdf:type owl:Class . _:x rdf:type rdfs:Class . [opt] _:x owl:intersectionOf T(SEQ(restriction(ID component₁) … restriction(ID component_n))) .	_: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] annotation₁ … annotation_m super(super₁)… super(super_n) domain(domain₁)… domain(domain_k) range(range₁)… range(range_h) [Functional])	ID rdf:type owl:DatatypeProperty . ID rdf:type rdf:Property . [opt] [ID rdf:type owl:DeprecatedProperty .] ID T(annotation₁) … ID T(annotation_m) ID rdfs:subPropertyOf T(super₁) . … ID rdfs:subPropertyOf T(super_n) . ID rdfs:domain T(domain₁) . … ID rdfs:domain T(domain_k) . ID rdfs:range T(range₁) . … ID rdfs:range T(range_h) . [ID rdf:type owl:FunctionalProperty . ]
ObjectProperty(ID [Deprecated] annotation₁ … annotation_m super(super₁)… super(super_n) domain(domain₁)… domain(domain_k) range(range₁)… range(range_h) [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(annotation₁) … ID T(annotation_m) ID rdfs:subPropertyOf T(super₁) . … ID rdfs:subPropertyOf T(super_n) . ID rdfs:domain T(domain₁) . … ID rdfs:domain T(domain_k) . ID rdfs:range T(range₁) . … ID rdfs:range T(range_h) . [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 annotation₁ … annotation_m)	ID rdf:type owl:AnnotationProperty . ID rdf:type rdf:Property . [opt] ID T(annotation₁) … ID T(annotation_m)
OntologyProperty(ID annotation₁ … annotation_m)	ID rdf:type owl:OntologyProperty . ID rdf:type rdf:Property . [opt] ID T(annotation₁) … ID T(annotation_m)
EquivalentProperties(dvpID₁ … dvpID_n)	T(dvpID_i) owl:equivalentProperty T(dvpID_i+1) . 1≤i<n
SubPropertyOf(dvpID₁ dvpID₂)	T(dvpID₁) rdfs:subPropertyOf T(dvpID₂) .
EquivalentProperties(ivpID₁ … ivpID_n)	T(ivpID_i) owl:equivalentProperty T(ivpID_i+1) . 1≤i<n
SubPropertyOf(ivpID₁ ivpID₂)	T(ivpID₁) rdfs:subPropertyOf T(ivpID₂) .
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 item₁…item_n	_:l₁ rdf:type rdf:List . [opt] _:l₁ rdf:first T(item₁) . _:l₁ rdf:rest _:l₂ . … _:ln rdf:type rdf:List . [opt] _:ln rdf:first T(item_n) . _:ln rdf:rest rdf:nil .	_:l₁

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.

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 Semantics], 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.

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 Semantics], 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 = < R_I, P_I, EXT_I, S_I, L_I, LV_I >. R_I is the domain of discourse or universe, i.e., a nonempty set that contains the denotations of URI references and literals in V. P_I is a subset of R_I, the properties of I. EXT_I is used to give meaning to properties, and is a mapping from P_I to P(R_I × R_I). S_I is a mapping from URI references in V to their denotations in R_I. L_I is a mapping from typed literals in V to their denotations in R_I. LV_I is a subset of R_I 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 C_I is defined as C_I = { x ∈R_I | <x,S_I(rdfs:Class)> ∈ EXT_I(S_I(rdf:type)) }, and the mapping CEXT_I from C_I to P(R_I) is defined as CEXT_I(c) = { x∈R_I | <x,c>∈EXT_I(S_I(rdf:type)) }. D-interpretations must meet several other conditions, as detailed in the RDF semantics. For example, EXT_I(S_I(rdfs:subClassOf)) must be a transitive relation and the class extension of all datatypes must be subsets of LV_I.

Definition: Let D be a datatype map that includes datatypes for rdf:XMLLiteral, xsd:integer and xsd:string. An OWL interpretation, I = < R_I, P_I, EXT_I, S_I, L_I, LV_I >, 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
owl:Class	C_I	IOC	IOC⊆C_I	This defines IOC as the set of OWL classes.
rdfs:Datatype		IDC	IDC⊆C_I	This defines IDC as the set of OWL datatypes.
owl:Restriction	C_I	IOR	IOR⊆IOC	This defines IOR as the set of OWL restrictions.
owl:Thing	IOC	IOT	IOT⊆R_I and IOT ≠ ∅	This defines IOT as the set of OWL individuals.
owl:Nothing	IOC	{}
rdfs:Literal	IDC	LV_I	LV_I⊆R_I
owl:ObjectProperty	C_I	IOOP	IOOP⊆P_I	This defines IOOP as the set of OWL individual-valued properties.
owl:DatatypeProperty	C_I	IODP	IODP⊆P_I	This defines IODP as the set of OWL datatype properties.
owl:AnnotationProperty	C_I	IOAP	IOAP⊆P_I	This defines IOAP as the set of OWL annotation properties.
owl:OntologyProperty	C_I	IOXP	IOXP⊆P_I	This defines IOXP as the set of OWL ontology properties.
owl:Ontology	C_I	IX		This defines IX as the set of OWL ontologies.
owl:AllDifferent	C_I	IAD
rdf:List		IL	IL⊆R_I	This defines IL as the set of OWL lists.
rdf:nil	IL
"l"^^d	CEXT_I(S_I(d))		S_I("l"^^d) ∈ LV_I	Typed literals are well-behaved in OWL.

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

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

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.

If E is	then if e∈CEXT_I(S_I(E)) then	Note
owl:Class	CEXT_I(e)⊆IOT	Instances of OWL classes are OWL individuals.
rdfs:Datatype	CEXT_I(e)⊆LV_I
owl:DataRange	CEXT_I(e)⊆LV_I	OWL dataranges are special kinds of datatypes.
owl:ObjectProperty	EXT_I(e)⊆IOT×IOT	Values for individual-valued properties are OWL individuals.
owl:DatatypeProperty	EXT_I(e)⊆IOT×LV_I	Values for datatype properties are literal values.
owl:AnnotationProperty	EXT_I(e)⊆IOT×(IOT∪LV_I)	Values for annotation properties are less unconstrained.
owl:OntologyProperty	EXT_I(e)⊆IX×IX	Ontology properties relate ontologies to other ontologies.
If E is	then c∈CEXT_I(S_I(E)) iff c∈IOOP∪IODP and	Note
owl:FunctionalProperty	<x,y₁>, <x,y₂> ∈ EXT_I(c) implies y₁ = y₂	Both individual-valued and datatype properties can be functional properties.
If E is	then c∈CEXT_I(S_I(E)) iff c∈IOOP and	Note
owl:InverseFunctionalProperty	<x₁,y>, <x₂,y>∈EXT_I(c) implies x₁ = x₂	Only individual-valued properties can be inverse functional properties.
owl:SymmetricProperty	<x,y> ∈ EXT_I(c) implies <y, x>∈EXT_I(c)	Only individual-valued properties can be symmetric properties.
owl:TransitiveProperty	<x,y>, <y,z>∈EXT_I(c) implies <x,z>∈EXT_I(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>∈EXT_I(S_I(E)) iff
rdfs:subClassOf	x,y∈IOC	CEXT_I(x) ⊆ CEXT_I(y)
rdfs:subPropertyOf	x,y∈IOOP	EXT_I(x) ⊆ EXT_I(y)
rdfs:subPropertyOf	x,y∈IODP	EXT_I(x) ⊆ EXT_I(y)
rdfs:domain	x∈IOOP∪IODP,y∈IOC	<z,w>∈EXT_I(x) implies z∈CEXT_I(y)
rdfs:range	x∈IOOP∪IODP,y∈IOC∪IDC	<w,z>∈EXT_I(x) implies z∈CEXT_I(y)

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

We will say that l₁ is a sequence of y₁,…,y_n over C iff n=0 and l₁=S_I(rdf:nil) or n>0 and l₁∈IL and ∃ l₂, …, l_n ∈ IL such that
<l₁,y₁>∈EXT_I(S_I(rdf:first)), y₁∈C, <l₁,l₂>∈EXT_I(S_I(rdf:rest)), …,
<l_n,y_n>∈EXT_I(S_I(rdf:first)), y_n∈C, and <l_n,S_I(rdf:nil)>∈EXT_I(S_I(rdf:rest)).

If E is	then <x,y>∈EXT_I(S_I(E)) iff
owl:complementOf	x,y∈ IOC and CEXT_I(x)=IOT-CEXT_I(y)
owl:unionOf	x∈IOC and y is a sequence of y₁,…y_n over IOC and CEXT_I(x) = CEXT_I(y₁)∪…∪CEXT_I(y_n)
owl:intersectionOf	x∈IOC and y is a sequence of y₁,…y_n over IOC and CEXT_I(x) = CEXT_I(y₁)∩…∩CEXT_I(y_n)
owl:oneOf	x∈C_I and y is a sequence of y₁,…y_n over IOT or over LV_I and CEXT_I(x) = {y₁,..., y_n}

If E is	and	then if <x,l>∈EXT_I(S_I(E)) then
owl:oneOf	l is a sequence of y₁,…y_n over LV_I	x∈IDC
owl:oneOf	l is a sequence of y₁,…y_n over IOT	x∈IOC

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

If there exists	then there exists l₁,…,l_n ∈ IL with
x₁, …, x_n ∈ IOC	<l₁,x₁> ∈ EXT_I(S_I(rdf:first)), <l₁,l₂> ∈ EXT_I(S_I(rdf:rest)), … <l_n,x_n> ∈ EXT_I(S_I(rdf:first)), <l_n,S_I(rdf:nil)> ∈ EXT_I(S_I(rdf:rest))
x₁, …, x_n ∈ IOT∪LV_I	<l₁,x₁> ∈ EXT_I(S_I(rdf:first)), <l₁,l₂> ∈ EXT_I(S_I(rdf:rest)), … <l_n,x_n> ∈ EXT_I(S_I(rdf:first)), <l_n,S_I(rdf:nil)> ∈ EXT_I(S_I(rdf:rest))
If there exists	then there exists y with
l, a sequence of x₁,…,x_n over IOT with x_i≠x_j for 1≤i<j≤n	y∈IAD, <y,l>∈EXT_I(S_I(owl:distinctMembers))
If there exists	then there exists y with
l, a sequence of x₁,…,x_n over IOC	y∈IOC, <y,l> ∈ EXT_I(S_I(owl:unionOf))
l, a sequence of x₁,…,x_n over IOC	y∈IOC, <y,l> ∈ EXT_I(S_I(owl:intersectionOf))
l, a sequence of x₁,…,x_n over IOT	y∈IOC, <y,l> ∈ EXT_I(S_I(owl:oneOf))
l, a sequence of x₁,…,x_n over LV_I	y∈IDC, <y,l> ∈ EXT_I(S_I(owl:oneOf))
If there exists	then there exists y ∈ IOC with
x ∈ IOC	<y,x> ∈ EXT_I(S_I(owl:complementOf))
If there exists	then there exists y ∈ IOR with
x ∈ IOOP∪IODP ∧ w ∈ IOC ∪ IDC	<y,x> ∈ EXT_I(S_I(owl:onProperty)) ∧ <y,w> ∈ EXT_I(S_I(owl:allValuesFrom))
x ∈ IOOP∪IODP ∧ w ∈ IOC ∪ IDC	<y,x> ∈ EXT_I(S_I(owl:onProperty)) ∧ <y,w> ∈ EXT_I(S_I(owl:someValuesFrom))
x ∈ IOOP∪IODP ∧ w ∈ IOT ∪ LV_I	<y,x> ∈ EXT_I(S_I(owl:onProperty)) ∧ <y,w> ∈ EXT_I(S_I(owl:hasValue))
x ∈ IOOP∪IODP ∧ w ∈ LV_I ∧ w is a non-negative integer	<y,x> ∈ EXT_I(S_I(owl:onProperty)) ∧ <y,w> ∈ EXT_I(S_I(owl:minCardinality))
x ∈ IOOP∪IODP ∧ w ∈ LV_I ∧ w is a non-negative integer	<y,x> ∈ EXT_I(S_I(owl:onProperty)) ∧ <y,w> ∈ EXT_I(S_I(owl:maxCardinality))
x ∈ IOOP∪IODP ∧ w ∈ LV_I ∧ w is a non-negative integer	<y,x> ∈ EXT_I(S_I(owl:onProperty)) ∧ <y,w> ∈ EXT_I(S_I(owl:cardinality))

5.3. OWL Full

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

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

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.

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: 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 = <R_I,P_I,EXT_I,S_I,L_I,LV_I> be a OWL DL interpretation of V that satisfies T(V'), with LV_I = LV. Let CEXT_I have its usual meaning, and, as usual, overload I to map any syntactic construct into its denotation. If

The proof of the lemma is by a structural induction. Throughout the proof, let IOT = CEXT_I(I(owl:Thing)), IOC = CEXT_I(I(owl:Class)), IDC = CEXT_I(I(rdfs:Datatype)), IOOP = CEXT_I(I(owl:ObjectProperty)), IODP = CEXT_I(I(owl:DatatypeProperty)), and IL = CEXT_I(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)>∈EXT_I(I(rdfs:domain)) and <p,I(owl:Thing)>∈EXT_I(I(rdfs:range)). Thus I satisfies T(p). Similarly for p∈VDP.

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 R_I 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 R_I such that I+A(M(T(d))) = r.

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 R_I, I+A OWL DL satisfies the triples resulting from the annotation iff I' direct satisfies the conditions resulting from the annotation.

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.

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.

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 = <R_I,P_I,EXT_I,S_I,L_I,LV_I> 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).

Let CEXT_I be defined as usual from I. The required direct interpretation will be I' = < R_I, EC, ER, L, S, LV_I > where

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

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

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

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

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

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

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

[10 April 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0046.html, added owl:Class, owl:Restriction, owl:ObjectProperty, owl:DatatypeProperty, owl:AnnotationProperty, owl:OntologyProperty, owl:Ontology, owl:AllDifferent, owl:FunctionalProperty, owl:InverseFunctionalProperty, owl:SymmetricProperty, and owl:TransitiveProperty to C_I in Section 5.2. Some of these were inferrable already.
[10 April 2003] Related to http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0046.html, added owl:distinctMembers to R_I in Section 5.2.
[15 April 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0064.html, added owl:OntologyProperty to the disallowed vocabulary in disallowed OWL vocabulary in Section 4.2.
[5 May 2003] Per a decision of the Web Ontology working group on 1 May 2003 to add owl:Nothing to OWL Lite, recorded in http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0017.html, changed the introduction of owl:Nothing to so indicate. The index for owl:Nothing was also updated.
[9 May 2003] To improve internal consistency, added optional rdf:Property types for Annotation Properties in Section 4.1.
[30 May 2003] Per a decision of the Web Ontology working group on 29 May 2003 to modify the mapping of EquivalentClasses, recorded in http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0402.html and in response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Apr/0003.html and http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0052.html, changed the mapping rule for EquivalentClasses(d1 ... dn) to T(di) owl:equivalentTo T(dj) . for all <i,j> in G where G is a set of pairs over {1,...,n} that if interpreted as an undirected graph forms a connected graph for {1,...,n}.
[30 May 2003] Per a decision of the Web Ontology working group on 29 May 2003 to add axioms for ontology properties, recorded in http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0402.html, added axioms for ontology properties to the OWL Lite and OWL DL abstract syntax in Sections 2.3.1.3. and Section 2.3.2.4; added direct semantics conditions for ontology property axioms in Section 3.3; and added a mapping for ontology property axioms in Section 4.1. Fixed the proofs of Lemma 2 and Lemma 3.
[30 May 2003] Per a decision of the Web Ontology working group on 29 May 2003 to change the semantics for owl:intersectionOf and related resources from an intensional semantics to an extensional semantics, recorded in http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0402.html, modified the semantic conditions for owl:intersectionOf, owl:unionOf, owl:complementOf, and owl:oneOf in Section 5.2. No change needed to be made to the proof of Lemma 1. Fixed the proofs of Lemma 4 and Lemma 2.
[2 June 2003] In response to an observation by Jeremy Carroll in http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0004.html, changed the mapping rule for anonymous individuals with no types slightly in Section 4.1.
[4 June 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0011.html, the treatment of datatypes and rdfs:Literal has been slightly changed in Section 2.3.1.3, Section 2.3.2.3, and Section 4.1.
[4 June 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0050.html, point owlsas-rdf-equivalent-class, modified the treatment of ontology annotations in Section 3.4.
[5 June 2003] In response to a comment by Jeremy Carroll in http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0004.html, the direct semantics has been modified to allow for domain elements that are not OWL individuals. These domain elements are used to provide meaning for annotations on classes, properties, and ontologies. Changes have been made in Section 3.1, Section 3.2, Section 3.3, and Appendix A.1.
[6 June 2003] Changed the treatment of datatypes to correspond with the substantive post-last-call fixes and changes to the treatment of datatypes in RDF. Changes have been made in Section 3.1 and Appendix A.1.
[26 June 2003] Per a decision of the Web Ontology working group on 26 June 2003 to replace owl:sameIndividualAs with owl:sameAs, recorded in http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0364.html, made changes to Section 2.2, Section 3.3, Section 4.1, Section 4.2, Section 5.2, and Appendix A.1.
[30 June 2003] Fixed a bug in the semantic conditions for owl:hasValue noticed by Jeremy Carroll, changing the conditions for the value from a property to an individual or a data value in Section 5.2.
[23 July 2003] In response to a substantive post-last-call change to the RDF semantics, changing the if-and-only-if conditions for rdfs:subClassOf and rdfs:subPropertyOf to only-if conditions, added if-and-only-if conditions for rdfs:subClassOf, over OWL classes, and rdfs:subPropertyOf, over OWL individual-valued properties and over OWL datatype properties, to Section 5.2.
[23 July 2003] In response to a substantive change to the RDF syntax mapping to triples, removing the typing triples for collections, [applicable document unknown], made typing of list resources optional in Section 4.1. Also modified an example in Appendix B.1.

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.

[9 April 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0023.html, point 2, changed ``most information about properties'' to ``most information concerning properties'' in Section 2.3.
[14 April 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html, point 1, added ``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.'' to the discussion of allowable XML Schema datatypes in Section 2.
[14 April 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html, point 2.1, added ``(The property rdf:type is added to the annotation properties so as to provide a meaning for deprecation, see below.)'' after ``ER provides meaning for URI references that are used as OWL properties.'' in Section 3.1.
[14 April 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html, point 2.3, added ``A datatype theory must contain datatypes for xsd:string and xsd:integer. It may contain datatypes for the other built-in XML Schema datatypes that are suitable for use in OWL. It may also contain other datatypes, but there is no provision in the OWL syntax for conveying what these datatypes are.'' just after the definition of a datatype theory in Section 3.1.
[14 April 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html, point 2.5, added ``annotations'' the the list of things that EC is extended to in Section 3.2.
[9 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0050.html, point owlsas-rdf-datatype-denotation, removed the phrase ``as in RDF'' from Section 2.1.
[9 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0050.html, point owlsas-rdf-equivalent-class, added an explanation of why one might admit EquivalentClasses with only one description in Section 2.3.2.1.
[9 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0050.html, added ``, for n>=1 '' in the semantic condition for multi-restrictions in Section 3.2.
[9 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0050.html, changed to ``include class identifiers and restrictions'' in Section 2.3.2.2 and ``Elements of the OWL vocabulary that construct descriptions'' in Section 5.2.
[13 May 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0180.html, the links in the table of contents for in Appendix A were fixed.
[14 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0030.html, added a new paragraph to the beginning of Section 4.
[14 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0057.html, made some changes to the wording on OWL ontologies in the abstract syntax near the beginning of Section 2.1.
[14 May 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0057.html, added anchors to the transformations in Section 4.1.
[14 May 2003] In response to some discussion about ontology names changed the discussion of the purpose of ontology names in Section 2.1.
[22 May 2003] In response to a message from Jeff Heflin, http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0302.html, added a comment to the effect tools should determine entailment between imports closures in Section 5.3 and Section 5.4. (Removed on 27 May 2003.)
[22 May 2003] Changed ``consistent with the Web'' to ``imports closed'' Section 5.3 and Appendix A.
[26 May 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0335.html, changed several `if' to `iff' in definitions in Section 3.4, Section 5.3, and Section 5.4. This is editorial as complete definitions are often written using `if'.
[30 May 2003] Fixed a typographical error in the proof of Lemma 4.
[4 June 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html, points 2.2 and 2.3, the status of rdfs:Literal and rdf:XMLLiteral has been clarified in Section 2, Section 2.1, and Section 4.2.
[19 June 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0257.html, changed to note after the proof of Theorem 2 in Appendix A.2 to note that the converse of the theorem is not true.
[19 June 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0055.html, changed some explanatory text concerning the transformation to triples in Section 4.1.
[19 June 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0264.html, added introductory material about the other WebOnt documents to Section 1.
[24 June 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0069.html, added note about correspondence to existing DLs to Section 2.
[22 July 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Jul/0011.html and http://lists.w3.org/Archives/Public/public-webont-comments/2003Jul/0041.html, changed several uses of ``object'' to ``individual'' or ``individual-valued'' in Section 2 and Section 5.2 and made other editorial changes to Section 5.2.
[23 July 2003] To remove any reference to tools, made wording changes in Section 3.1 and Section 2.1, concerning the treatment of datatypes.
[25 July 2003] In response to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0064.html, added explicit tagging of the informative or normative nature of all sections.
[25 July 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Jul/0296.html, removed a comment about the relationship between the two model theories from Section 1.
[6 August 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Jul/0015.html, changed owl:IndividualProperty to owl:ObjectProperty in Appendix A.2.
[6 August 2003] In response to Section 2.1, concerning the treatment http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0064.html, added quotes around rdfs:Literal to indicate that it is a terminal, not a non-terminal, in Section 2.3.1.3 and Section 2.3.2.3.

C.3 Substantive changes after Candidate Recommendation

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

[18 September 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Sep/0156.html, made the type triples for the individualvaluedPropertyID production in Section 4.1 optional if typing triples would be produced from some other production.
[3 October 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Sep/0177.html, augmented the mapping from the abstract syntax to triples to allow for collections of axioms and facts outside of ontologies to generate OWL DL in triples made the type triple for anonymous ontologies optional unless the ontology has annotations. Upgraded the definition of entailment in the direct model theory to allow entailment to work over collections of axioms and facts outside of ontologies. Changes were made in Section 3.4, Section 4.2, and Section 5.4. Many of the proofs in Appendix A required minor changes.
[6 November 2003] In response to proposal http://lists.w3.org/Archives/Public/www-webont-wg/2003Oct/0167.html and in accordance with a decision of the working group http://lists.w3.org/Archives/Public/www-webont-wg/2003Nov/0000.html, added the condition that EC(owl:Thing) must be nonempty in Section 3.1 and that IOT must be nonempty in Section 5.2.
[29 November 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Nov/0064.html and http://lists.w3.org/Archives/Public/www-webont-wg/2003Nov/0132.html, made changes to Section 5.2 to bring the treatment of datatypes into line with the latest version of the RDF semantics [RDF Semantics].
[29 November 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Nov/0064.html, added a note to the beginning of Section 5 (and a reference to this note in Section 5.4) explicitly stating that the Direct Model-Theoretic Semantics takes precedence over the OWL DL semantics.

C.4 Editorial changes after Candidate Recommendation

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

[29 November 2003] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Nov/0132.html, made several editorial changes to Sections 2, 3, 4 and 5.

[3 December 2003] In further response to http://lists.w3.org/Archives/Public/www-webont-wg/2003Nov/0132.html and ensuing discussion, made several editorial changes to Sections 3 and 5 and Appendix A.

C.5 Changes since Proposed Recommendation

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

[21 December 2003] Fixed typographical error: Recommentation → Recommendation (in several places).
[29 January 2004] In response to http://lists.w3.org/Archives/Public/www-webont-wg/2004Jan/0021.html, clarified the definition of separated vocabulary in Section 4.2.
[29 January 2004] In response to http://www.ilrt.bris.ac.uk/discovery/chatlogs/webont/2004-01-29#T17-08-44, made explicit in the definition of an RDF compatible OWL interpretation in Section 5.2 that an RDF compatible datatype map necessarily includes a datatype for rdf:XMLLiteral.

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

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 alSafadi, 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, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael Sintek, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, and John Yanosy.

If E is	then			Note
If E is	S_I(E)∈	CEXT_I(S_I(E))=	and	Note
owl:Class	C_I	IOC	IOC⊆C_I	This defines IOC as the set of OWL classes.
rdfs:Datatype		IDC	IDC⊆C_I	This defines IDC as the set of OWL datatypes.
owl:Restriction	C_I	IOR	IOR⊆IOC	This defines IOR as the set of OWL restrictions.
owl:Thing	IOC	IOT	IOT⊆R_I and IOT ≠ ∅	This defines IOT as the set of OWL individuals.
owl:Nothing	IOC	{}
rdfs:Literal	IDC	LV_I	LV_I⊆R_I
owl:ObjectProperty	C_I	IOOP	IOOP⊆P_I	This defines IOOP as the set of OWL individual-valued properties.
owl:DatatypeProperty	C_I	IODP	IODP⊆P_I	This defines IODP as the set of OWL datatype properties.
owl:AnnotationProperty	C_I	IOAP	IOAP⊆P_I	This defines IOAP as the set of OWL annotation properties.
owl:OntologyProperty	C_I	IOXP	IOXP⊆P_I	This defines IOXP as the set of OWL ontology properties.
owl:Ontology	C_I	IX		This defines IX as the set of OWL ontologies.
owl:AllDifferent	C_I	IAD
rdf:List		IL	IL⊆R_I	This defines IL as the set of OWL lists.
rdf:nil	IL
"l"^^d	CEXT_I(S_I(d))		S_I("l"^^d) ∈ LV_I	Typed literals are well-behaved in OWL.

Status of this document

1. Introduction (Informative)