Syntax Test Copy

1 Introduction

This document defines the OWL 2 language. The core part of this specification — called the structural specification — is independent of the concrete exchange syntaxes for OWL 2 ontologies. It describes the conceptual structure of OWL 2 ontologies and thus provides a normative abstract model for all (normative and nonnormative) syntaxes of OWL 2. This allows for a clear separation of the essential features of the language from issues related to any particular syntax. Furthermore, such a structural specification of OWL 2 provides the foundation for the implementation of OWL 2 tools such as APIs and reasoners.

This document also defines the functional-style syntax, which closely follows the structural specification and allows OWL 2 ontologies to be written in a compact form. This syntax is extensively used in the other OWL 2 documents. It is used in the definition of the semantics for OWL 2, the mapping from into the RDF/XML exchange syntax, and the different profiles of OWL 2.

An OWL 2 ontology is a formal conceptualization of a domain of interest. OWL 2 ontologies consist of the following three different syntactic categories:

• Entities, such as classes, properties, and individuals, are the things that are identified by IRIs (URIs) and can be thought of as primitive terms or names. Entities represent basic elements of the domain being modeled. For example, a class a:Person can be used to model the set of all people. Similarly, the object property a:parentOf can be used to model the fact that a person is a parent of another person. Finally, the individual a:Peter can be used to represent a particular person called "Peter".
• Expressions represent complex notions in the domain being modeled. For example, a class expression describes a set of individuals in terms of the restrictions on the individuals' features.
• Axioms are statements that are deemed to be true in the domain being modeled. For example, using a subclass axiom, one can state that the class a:Student is a subclass of the class a:Person.

These three syntactic categories are used to express the logical part of OWL 2 ontologies — that is, they are interpreted under a precisely defined semantics that allows one to draw useful inferences. For example, if an individual a:Peter is an instance of the class a:Student, and a:Student is a subclass of a:Person, then by the OWL 2 semantics one can derive that a:Peter is an instance of a:Person.

In addition, entities, axioms, and ontologies can be annotated in OWL 2. For example, a class can be given a human-readable label that provides an intuitive name for the class. Annotations have no effect on the logical aspects of an ontology — that is, for the purposes of the OWL 2 semantics, annotations are treated as not being present. Instead, the use of annotations is left to the applications that use OWL 2. For example, a graphical user interface can choose to visualize each class using one of its labels.

OWL 2 provides basic support for ontology modularization. In particular, an OWL 2 ontology O can import another OWL 2 ontology O' and thus gain access to all entities, expressions, and axioms in O'.

Concrete syntaxes, such as the functional-style syntax defined in this document, often provide features not found in the structural specification, such as a mechanism for abbreviating long URIs.

1.1 Normative Status of this Document

This document only defines the structural specification of OWL 2, the functional syntax for OWL 2, and the behavior of datatype maps. Only the parts of the document related to these three purposes are normative. The examples in this document are informative and any part of the document that is specifically noted as informative is not normative. Finally, the informal descriptions of the semantics of OWL 2 constructs in this document are informative; the semantics is precisely specified in a separate document [OWL 2 Direct Semantics].

The italicized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY specify certain aspects of the normative behavior of OWL 2 tools, and are interpreted as specified in RFC 2119 [RFC 2119].

2 Preliminary Definitions

This section presents certain preliminary definitions that are used in the rest of this document.

2.1 UML Notation and Structural Equivalence

The structural specification of OWL 2 is defined using the Unified Modeling Language (UML), and the used notation is compatible with the Meta-Object Facility (MOF). This document uses only a very simple form of UML class diagrams that are expected to be intuitively understandable to readers that are familiar with the basic concepts of object-oriented systems, even if they are not familiar with UML. The names of abstract classes (i.e., the classes that are not intended to be instantiated) are written in italic.

Elements of the structural specification are connected by associations, many of which are of one-to-many type. Whether the elements participating in associations are ordered and whether repetitions are allowed is made clear by the following standard UML conventions:

• By default, all associations are sets; that is, the elements in them are unordered and repetitions are disallowed.
• The { ordered,nonunique } attribute is placed next to the association ends that are ordered and in which repetitions are allowed. Such associations have the semantics of lists.

Whether two elements of the structural specification are considered to be the same is captured by the notion of structural equivalence, defined as follows. Elements o₁ and o₂ are structurally equivalent if and only if the following conditions hold:

• If o₁ and o₂ are atomic values, such as strings, integers, or IRIs (URIs), they are structurally equivalent if they are identical according to the notion of identity specified by the respective atomic type.
• If o₁ and o₂ are unordered associations without repetitions, they are structurally equivalent if each element of o₁ is structurally equivalent to some element of o₂ and vice versa.
• If o₁ and o₂ are ordered associations with repetitions, they are structurally equivalent if they contain the same number of elements and each element of o₁ is structurally equivalent to the element of o₂ with the same index.
• If o₁ and o₂ are complex elements consisting of other elements, they are structurally equivalent if
  • both o₁ and o₂ are of the same type,
  • each element of o₁ is structurally equivalent to the corresponding element of o₂, and
  • each association of o₁ is structurally equivalent to the corresponding association of o₂.

Note that structural equivalence is not a semantic notion, as it is based only on comparing structures.

Although set associations are widely used in the specification, sets written in one of the linear syntaxes (e.g., XML or RDF/XML) are not expected to be duplicate free. Duplicates SHOULD be eliminated from such constructs during parsing.

2.2 BNF Notation

The functional-style syntax of OWL 2 is defined using the standard BNF notation, which is summarized in Table 1. Documents containing OWL 2 ontologies written in functional-style syntax SHOULD use the UTF-8 encoding.

2.3 URIs and Namespaces

Ontologies and their elements are identified using International Resource Identifiers (IRIs) [RFC 3987]. OWL 1 uses Uniform Resource Identifiers (URIs) as identifiers. To avoid introducing new terminology, this specification uses the term 'URI' hereafter to mean 'IRI'.

In the functional-style syntax, IRIs can either be given in full or they can be abbreviated using CURIEs [CURIE].

An abbreviated IRI matching the abbreviated-IRI production is turned into a full IRI as specified next. The resulting IRI MUST be a valid IRI; otherwise, the functional-style syntax document is syntactically invalid.

• The value matching to abbreviated-IRI production is split into a prefix, matching the prefix production, and a reference, matching the reference production.
• If the prefix is empty, then the resulting full IRI is equal to the reference.
• If the prefix is not empty, it is looked up in the namespace definitions (defined in Section 3) of the ontology being parsed.
  • If the namespace definitions do not contain the prefix, then the functional-style syntax document is syntactically invalid.
  • If the namespace definitions map the prefix to a namespace name, then the resulting full IRI is obtained by concatenating the namespace name with the reference.

Table 2 defines the standard namespaces and the respective prefixes used throughout this specification.

URIs from the rdf, rdfs, xsd, and owl namespaces constitute the reserved vocabulary of OWL 2. As described in the following sections, the URIs from the reserved vocabulary that are listed in Table 3 have special treatment in OWL 2. All other URIs from the reserved vocabulary constitute the disallowed vocabulary of OWL 2 and MUST NOT be used in OWL 2 ontologies.

2.4 Integers, Strings, Language Tags, and Node IDs

Several types of syntactic elements are commonly used in this document. Nonnegative integers are defined as usual.

Characters and strings are defined in the same way as in [RDF:TEXT]. A character is an atomic unit of communication. The structure of characters is not further specified in OWL 2, other than to note that each character has a Universal Character Set (UCS) code point [ISO/IEC 10646]. The set of available characters is assumed to be infinite, and it thus independent from the currently actual version of UCS. A string is a finite sequence of characters, and the length of a string is the number of characters in it. In the functional-style syntax, strings are written as specified in [RDF:TEXT]: they are enclosed in double quotes, and a subset of the quoting mechanism of the N-triples specification [RDF Test Cases] is used to encode strings containing quotes.

Language tags are nonempty strings as defined in BCP 47 [BCP 47]. In the functional-style syntax, language tags are not enclosed in double quotes; however, this does not lead to parsing problems since, according to BCP 47, language tags contain neither whitespace nor the parentheses '(' and ')'.

Node IDs are borrowed from the N-Triples specification [RDF Test Cases].

3 Ontologies

The main component of an OWL 2 ontology is the set of axioms that the ontology contains. Because an ontology consists of a set of axioms, an ontology cannot contain two axioms that are structurally equivalent. OWL 2 ontology documents are not expected to enforce this; however, when reading OWL 2 ontologies stored in documents, an OWL 2 implementation MUST eliminate structurally equivalent duplicate axioms. The structure of axioms is described in more detail in Section 9. Apart from axioms, ontologies can also contain annotations, and they can import other ontologies as well. The structure of OWL 2 ontologies is shown in Figure 1.

The namespace production defines an abbreviation for namespaces in a document. In each document, only one namespace declaration MUST exist for a given prefix. These prefixes are then used to expand abbreviated IRIs as specified in Section 2.3.

3.1 Ontology URI and Version URI

Each ontology MAY have an ontology URI, which is used to identify an ontology. If an ontology has an ontology URI, the ontology MAY additionally have a version URI, which is used to identify the version of the ontology. The version URI MAY, but need not be equal to the ontology URI. An ontology without an ontology URI MUST NOT contain a version URI.

To prevent problems with identifying ontologies, the following nonnormative guidance is provided:

• If an ontology has an ontology URI but no version URI, then a different ontology with the same ontology URI but no version URI SHOULD NOT exist.
• If an ontology has both an ontology URI and a version URI, then a different ontology with the same ontology URI and the same version URI SHOULD NOT exist.
• All other combinations of the ontology URI and version URI are not required to be unique. Thus, two different ontologies MAY have no ontology URI and no version URI; similarly, an ontology containing only an ontology URI MAY coexist with another ontology with the same ontology URI and some other version URI.

This specification provides no mechanism for enforcing these constraints in the entire Web. Rather, the presented rules are to be taken as guidelines when naming new ontologies, and they MAY be used by OWL 2 tools to detect problems.

The ontology URI and the version URI together identify a particular version from an ontology series — the set of all the versions of a particular ontology identified using a common ontology URI. In each ontology series, exactly one ontology version is regarded as the current one. Structurally, a version of a particular ontology is an instance of Ontology from the structural specification. Ontology series are not represented explicitly in the structural specification of OWL 2; therefore, they exists only as a side-effect of the naming conventions described in this and the following sections.

3.2 Locations of OWL 2 Ontologies

The ontology and the version URI, if present, determine the location of an ontology O according to the following rules:

• If O does not contain an ontology URI (and, consequently, is without a version URI as well), then O MAY be located anywhere.
• If O contains an ontology URI ou but no version URI, then O SHOULD be located at the location ou.
• If O contains an ontology URI ou and a version URI vu, then O SHOULD be located at the location vu; furthermore, if O is the current version of the ontology series with the URI ou, then it SHOULD also be located at the location ou.

Thus, the current version of an ontology series with some URI ou SHOULD be accessed from ou. To access a particular version of ou, one needs to know that version's version URI vu; then, the ontology SHOULD be accessed from vu.

OWL 2 tools will often need to implement functionality such as caching or off-line processing, where the location of stored ontologies differs from their locations as dictated by their ontology URI and version URI. In such cases, OWL 2 tools MAY implement a location redirection mechanism: when the user requests to open an ontology at location u, the tool MAY translate u to a different location u' and access the ontology from there. The result of parsing the ontology located at u' MUST be the same as if the ontology were retrieved from u. Furthermore, once the ontology is parsed, it SHOULD satisfy the three conditions from the beginning of this section in the same way as if it were retrieved from u. This specification does not specify any particular location redirection mechanisms — these are assumed to be implementation dependent.

3.3 Versioning of OWL 2 Ontologies

The conventions regarding the location of ontologies described in Section 3.2 provide a simple mechanism for versioning OWL 2 ontologies. An ontology series is identified using an ontology URI, and each version in the series is assigned a different version URI. The ontology representing the current version of the series SHOULD be located at the ontology URI and, if present, at its version URI as well; previous versions are located solely at their respective version URIs. When a new version O in the ontology series is created, the ontology O SHOULD replace the one located at the ontology URI (and it SHOULD also be accessible from its version URI).

3.4 Imports

An ontology can import other ontologies in order to gain access to their entities, expressions, and axioms, thus providing for ontology modularization.

Figure 1 presents the logical view of the import relation, which holds between two ontologies. In concrete syntaxes, however, the importing ontology only contains a URI identifying the location of the imported ontology. This location SHOULD be interpreted as specified in Section 3.2 in order to access the imported ontology.

An ontology O directly imports an ontology O' if O contains an import construct whose value is a URI u and O' is the ontology located at u. The relation imports is defined as a transitive closure of the relation directly imports. Finally, the import closure of O consists of O and each ontology that O imports.

The import closure of an ontology SHOULD NOT contain ontologies O₁ and O₂ such that

• O₁ and O₂ are different ontology versions from the same ontology series, or
• O₁ contains an ontology annotation owl:incompatibleWith with the value equal to either the ontology URI or the version URI of O₂.

The axiom closure of an ontology O is the smallest set that contains all the axioms from each ontology O' in the import closure of O with all anonymous individuals renamed apart — that is, the anonymous individuals from different ontologies in the import closure of O are treated as being different; please refer to Section 5.6.2 for more information.

In OWL 1, owl:imports was a special ontology property that was used to specify that an ontology imports another ontology. In OWL 2, imports are not ontology annotations, but are a separate primitive; the owl:imports annotation property has no built-in meaning in OWL 2.

3.5 Ontology Annotations

An OWL 2 ontology contains a set of annotations. These can be used to associate information with an ontology such as the ontology creator's name. As discussed in Section 10 in more detail, each annotation consists of an annotation property and an annotation value, and the latter can be a literal, an entity, or an anonymous individual. Ontology annotations do not affect the logical meaning of the ontology.

OWL 2 provides several built-in annotation properties for ontology annotations. The usage of these annotation properties on entities other than ontologies is discouraged.

• An owl:priorVersion annotation value is the location of the prior version of the containing ontology.
• An owl:backwardCompatibleWith annotation value is the location of a prior version of the containing ontology that is compatible with this ontology.
• An owl:incompatibleWith annotation value is the location of a prior version of the containing ontology that is incompatible with this ontology.

4 Datatype Maps

OWL 2 ontologies can contain values with built-in semantics, such as strings or integers. Such values are often called concrete, in order to distinguish them from the abstract values which are modeled using classes and individuals. Each kind of such values is called a datatype, and the set of all supported datatypes is called a datatype map. A datatype map is not a syntactic construct that is included into OWL 2 ontologies; therefore, it is not included in the structural specification of OWL 2. A datatype in a datatype map is identified by a URI, and it can be used in an OWL 2 ontology as described in Section 5.2.

More precisely, a datatype map is a 6-tuple D = ( N_DT , N_LT , N_FA , ⋅ ^DT , ⋅ ^LT , ⋅ ^FA ) with the following components.

• N_DT is a set of datatypes, each of which is identified by a URI, not containing the datatype rdfs:Literal.
• N_LT is a function that assigns to each datatype DT ∈ N_DT a set of literals N_LT(DT). The set N_LT(DT) is called the lexical space of DT. The set of all literals for all datatypes in D is denoted also with N_LT; whether N_LT is used as a function or as the set of all literals is expected to be clear from the context. A literal for a datatype DT has the form "abc"^^DT, where abc is a string called the lexical value of the literal.
• N_FA is a function that assigns to each datatype DT ∈ N_DT a set N_FA(DT) of pairs of the form 〈 f lt 〉, where f is a constraining facet, each of which is identified by a URI, and lt ∈ N_LT. Note that lt can be a literal of a datatype other than DT. The set N_FA(DT) is called the facet space of DT.
• For each datatype DT ∈ N_DT, the interpretation function ⋅ ^DT assigns to DT a set (DT)^DT called the value space.
• For each datatype DT ∈ N_DT and each literal lt ∈ N_LT(DT), the interpretation function ⋅ ^LT assigns to lt a data value (lt)^LT ∈ (DT)^DT.
• For each datatype DT ∈ N_DT and each pair 〈 f lt 〉 ∈ N_FA(DT), the interpretation function ⋅ ^FA assigns to 〈 f lt 〉 a facet value (〈 f lt 〉)^FA ⊆ (DT)^DT.

For simplicity, statements of the form "the value of a literal is in the value space of a certain datatype" are sometimes informally abbreviated to statements of the form "a literal is in a certain datatype" in this specification.

To include a datatype DT into a datatype map, one thus needs to provide the lexical space N_LT(DT), the facet space N_FA(DT), the value space (DT)^DT, the value (lt)^LT for each lt ∈ N_LT(DT), and a facet value (〈 f lt 〉)^FA for each 〈 f lt 〉 ∈ N_FA(DT). Such a specification is often identified with DT and is often also called a datatype; the intended meaning of the term "datatype" is expected to be clear from the context.

The OWL 2 datatype map consists of datatypes described in the rest of this section, most of which are based on XML Schema Datatypes [XML Schema Datatypes]. The definitions of these datatypes in OWL 2 are largely the same as in XML Schema; however, there are minor differences, all of which are clearly identified in the following sections. These differences were introduced mainly to align the semantics of OWL 2 datatypes with practical use cases.

As shown in the OWL 2 Semantics [OWL 2 Direct Semantics], the semantic consequences of an ontology depend exclusively on the set of actually used datatypes. Implementations are therefore free to extend the datatype map described in this section with extra datatypes without affecting the consequences of OWL 2 ontologies that do not use these datatypes.

4.1 Numbers

OWL 2 provides a rich set of datatypes, listed in Table 4, for representing various kinds of numbers.

Value Spaces. The value spaces of all numeric datatypes are shown in Table 4. The value space of owl:realPlus contains the value spaces of all other numeric datatypes. The special values -0, +INF, -INF, and NaN are not identical to any number. In particular, -0 is not a real number and it is not identical to real number zero; to stress this distinction, the real number zero is often called a positive zero, written +0.

Literals. Datatypes owl:realPlus and owl:real do not directly provide any literals — that is, no "abc"^^owl:realPlus ("abc"^^owl:real) is a literal of owl:realPlus (owl:real).

For DT a datatype different from owl:realPlus and owl:real, a literal of the form "abc"^^DT is a literal of DT if "abc" is a correct lexical value for DT as specified in XML Schema Datatypes [XML Schema Datatypes].

Each literal of the form "abc"^^DT is assigned a data value by interpreting "abc" as specified in XML Schema Datatypes [XML Schema Datatypes] for DT, with the difference that "-0"^^xsd:float and "-0"^^xsd:double are are both assigned the data value -0. Note that, according to this definition, the data value of, say, "-0"^^xsd:integer is positive zero (since negative zero is not a value in the value space of xsd:integer).

The literals of xsd:decimal and the datatypes derived from xsd:integer are mapped to arbitrarily large and arbitrarily precise numbers. An OWL 2 implementation MAY support all such literals; however, it MUST support at least the following literals, called core literals, which can be easily mapped to the primitive datatypes commonly found in modern implementation platforms:

• All xsd:float and xsd:double literals are core literals.
• A literal of type xsd:integer or of a type derived from xsd:integer is a core literal if its data value is in the value space of xsd:long.
• A literal of type xsd:decimal is a core literal if its data value is a number with absolute value less than 10¹⁶ and the representation of the number requires at most 16 digits in total.

Equality and Ordering. The facet space of the numeric datatypes are based on the following definitions of equality and ordering.

The equality = is the smallest symmetric relation on the value space of owl:realPlus such that all of the following conditions hold:

• x = x if x is a real number, -0, -INF, or +INF; and
• -0 = +0.

Note that NaN is not equal to itself; furthermore, even though -0 is equal to +0, it is not identical to it.

The ordering < is the smallest relation on the value space of owl:realPlus such that all of the following conditions hold:

• x < y if x and y are real numbers and x is smaller than y;
• -INF < x < +INF for each real number x;
• -0 < x for each positive real number x; and
• x < -0 for each negative real number x.

Facet Space. The facet space of each numeric datatype DT is shown in Table 5. Note that lt can be a literal of a numeric datatype other than DT.

Relationship with XML Schema. Numeric datatypes of OWL 2 are closely related to numeric datatypes in XML Schema [XML Schema Datatypes]; however, they differ from XML Schema Datatypes in the following aspects:

• All numeric datatypes are subsets of the value space of owl:realPlus; thus, unlike in XML Schema, the value spaces of xsd:float and xsd:double are in OWL 2 NOT disjoint with the value space of xsd:decimal.
• The value spaces of owl:realPlus, xsd:float, and xsd:double contain negative zero. In this way, the datatype system of OWL 2 has been aligned with the IEEE 754 [IEEE 754] standard for the representation of floating-point numbers.
• The special value NaN is identical but not equal to itself.

4.2 Strings

4.2.1 Strings with a Language Tag

OWL 2 uses the rdf:text datatype [RDF:TEXT] for the representation of strings in a particular language. The notion of a string used in the definition of rdf:text is the same as in Section 2.4.

Value Space. The value space of rdf:text is the set of all pairs of the form 〈 "text" , "lang" 〉, where "text" is a string and "lang" is either the empty string "" or a lowercase language tag as specified in BCP 47 [BCP 47].

Literals. The rdf:text datatype supports literals of the form "val"^^rdf:text, where "val" is a string that contains at least one character @ and satisfies the following condition: let i be the position of the last character @ in "val", and let "abc" and "tag" be the substrings of "val" containing the characters up to and after position i (noninclusive), respectively; then "tag" is either empty or a valid language tag. Each such literal is assigned a data value 〈 "abc", "lc-tag" 〉, where "lc-tag" is the string "tag" converted to lowercase.

Facet Space. The facet space of the rdf:text datatype is shown in Table 6.

4.2.2 Strings without a Language Tag

As recommended in [RDF:TEXT], the following XML Schema Datatypes [XML Schema Datatypes] are interpreted in OWL 2 as restrictions of rdf:text:

• xsd:string
• xsd:normalizedString
• xsd:token
• xsd:language
• xsd:Name
• xsd:NCName
• xsd:NMTOKEN
• xsd:ID
• xsd:IDREF
• xsd:ENTITY

Value Spaces. For DT a datatype from the above list, the value space (DT)^DT is a set of pairs of the form 〈 "abc" , "" 〉, where "abc" is a string matching the restrictions of DT as specified in XML Schema Datatypes [XML Schema Datatypes] and "" is the empty string.

Literals. Each datatype DT from the above list supports literals of the form "abc"^^DT, where "abc" is a string matching the restrictions of DT as specified in XML Schema Datatypes [XML Schema Datatypes].

Facet Space. Each datatype DT from the above list supports the constraining facets xsd:minLength, xsd:maxLength, xsd:length, and xsd:pattern. The facet value of each pair for DT is the same as in Table 6, with the difference that the result is a subset of (DT)^DT instead of (rdf:text)^DT.

Relationship with XML Schema. Unlike OWL 2, the datatypes listed in this section are interpreted in XML Schema as simple strings rather than pairs. This departure from XML Schema has been introduced in OWL 2 in order to make the value spaces of these datatypes subsets of the value space of rdf:text. Since the language part of each pair is empty, the value spaces of these datatypes in OWL 2 are isomorphic with the respective value spaces in XML Schema. Hence, this difference in the value spaces does not affect the logical consequences of OWL 2 ontologies that do not use rdf:text.

4.3 Boolean Values

The xsd:boolean datatype allows for the representation of Boolean values.

Value Space. The value space of xsd:boolean is the set containing exactly the two values true and false. These values are not contained in the value space of any other datatype.

Literals. The xsd:boolean datatype supports the following literals:

• "true"^^xsd:boolean and "1"^^xsd:boolean are assigned the data value true, and
• "false"^^xsd:boolean and "0"^^xsd:boolean are assigned the data value false.

Facet Space. The xsd:boolean datatype does not support any constraining facets.

4.4 Binary Data

Datatypes xsd:hexBinary and xsd:base64Binary allow for the representation of binary data. The two datatypes are the same apart from fact that they support a different syntactic representation for literals.

Value Spaces. The value space of both xsd:hexBinary and xsd:base64Binary is the set of finite sequences of octets — integers between 0 and 255, inclusive.

Literals. Datatypes xsd:hexBinary and xsd:base64Binary allow for literals of the form "abc"^^xsd:hexBinary and "abc"^^xsd:base64Binary, where "abc" is a string a specified in Section 3.2.15 and 3.2.16 of XML Schema Datatypes [XML Schema Datatypes], respectively. Such literals are mapped to data values as specified in XML Schema Datatypes [XML Schema Datatypes].

Facet Space. The facet space of the xsd:hexBinary and xsd:base64Binary datatypes is shown in Table 7.

4.5 URIs

The xsd:anyURI datatype allows for the representation of Uniform Resource Identifiers.

Value Space. The value space of xsd:anyURI is the set URIs as defined in XML Schema Datatypes [XML Schema Datatypes]. Although each URI has a string representation, the value space of xsd:anyURI is disjoint with the value space of xsd:string. The string representation of URIs, however, can be described by a regular expression, so the value space of xsd:anyURI is isomorphic to the value space of xsd:string restricted with a suitable regular expression.

Literals. The xsd:anyURI datatype supports literals of the form "abc"^^xsd:anyURI where "abc" is a string as in Section 3.2.17 of XML Schema Datatypes [XML Schema Datatypes].

Note that literals of xsd:anyURI include relative URIs. If an OWL 2 syntax employs rules for the resolution of relative URIs (e.g., the OWL 2 XML Syntax [OWL 2 XML Syntax] uses xml:base for that purpose), such rules do not apply to xsd:anyURI literals that represent relative URIs; that is, literals representing relative URIs MUST be parsed as they are.

Facet Space. The facet space of the xsd:anyURI datatype is shown in Table 8.

4.6 Time Instants

OWL 2 provides the owl:dateTime datatype for the representation of time instants. This datatype is based on, but is not equivalent to the xsd:dateTime datatype of XML Schema Datatypes [XML Schema Datatypes].

Value Space. The value space of owl:dateTime is the set of numbers, where each number x represents the time instant occurring x seconds after the first time instant of the 1st of January 1 AD in the proleptic Gregorian calendar [ISO 8601:2004] (i.e., the calendar in which the Gregorian dates are retroactively applied to the dates preceding the introduction of the Gregorian calendar). This set can be seen as a "copy" of the set of real numbers — that is, it is disjoint with but isomorphic to the value space of owl:real. For simplicity, the elements from this sets can be identified with real numbers.

Literals. The owl:dateTime datatype supports literals of the form "rep"^^owl:dateTime where "rep" is a string defined by the following grammar (whitespace within the grammar is irrelevant and single quites are used to introduce terminal symbols):

The components of the this string are as follows:

• Characters '-', 'T', and ':' separate the various parts of the string.
• year is an integer consisting of at least four decimal digits optionally preceded by a minus sign; leading 0 digits are prohibited except to bring the digit count up to four.
• month, day, hour, and minute are integers consisting of exactly two decimal digits.
• second is an integer consisting of exactly two decimal digits, or two decimal digits, a decimal point, and one or more trailing digits.
• timezone specifies a count of minutes that has to be added to or subtracted from UTC in order to get local time. The grammar for timezone is given by the following three alternatives, each of which is mapped to an integer as specified next:
  • a time point of the form '+' tzHours ':' tzMinutes between +00:00 (inclusive) and +14:00 (exclusive) is mapped to the value + tzHours × 60 + tzMinutes;
  • a time point of the form '-' tzHours ':' tzMinutes between -00:00 (inclusive) and -14:00 (exclusive) is mapped to the value - tzHours × 60 + tzMinutes;
  • 'Z' is mapped to the value 0.
• month is between 1 and 12 (inclusive).
• day is no more than 30 if month is one of 4, 6, 9, or 11; no more than 28 if month is 2 and year is not divisible 4, or is divisible by 100 but not by 400; and no more than 29 if month is 2 and year is divisible by 400, or by 4 but not by 100.
• hour, minute, and second represent a time point between 00:00:00 (inclusive) and 24:00:00 (exclusive).

Each such literal is assigned a data value as specified by the following function, where div represents integer division and mod is the remainder of integer division. This mapping does not take into account leap seconds: leap seconds will be introduced in UTC as deemed necessary in future; since the precise date when this will be done is not known, the OWL 2 specification ignores leaps seconds.

Literals of owl:dateTime can represent an arbitrary date. An OWL 2 implementation MAY support all such literals; however, it MUST support at least all literals in which the absolute value of the year component is less than 10000 (i.e., whose representation requires at most four digits), and in which the second component is a number with at most three decimal digits.

Facet Space. The facet space of the owl:dateTime datatype is shown in Table 9.

5 Entities and Literals

Entities are the fundamental building blocks of OWL 2 ontologies, and they define the vocabulary — the named terms — of an ontology. In logic, the set of entities is usually said to constitute the signature of an ontology. Apart from entities, OWL 2 ontologies typically also contain literals, such as strings or integers.

The structure of entities and literals in OWL 2 is shown in Figure 2. Classes, datatypes, object properties, data properties, annotation properties, and named individuals are entities, and they are all are uniquely identified by a URI. Classes can be used to model sets of individuals; datatypes are sets of literals such as strings or integers; object and data properties can be used to represent relationships in the modeled domain; annotation properties can be used to associate nonlogical information with ontologies, axioms, and entities; and named individuals can be used to represent actual objects from the domain being modeled. Apart from named individuals, OWL 2 also provides for anonymous individuals — that is, individuals that are analogous to blank nodes in RDF [RDF Syntax] and that are accessible only from within the ontology they are used in. Finally, OWL 2 provides for literals, which consist of a lexical value and a datatype specifying how to interpret this value.

5.1 Classes

Classes can be understood as sets of individuals.

URIs used to identify classes MUST NOT be in the reserved vocabulary, apart from owl:Thing and owl:Nothing, which are available in OWL 2 as built-in classes with a predefined semantics.

• The class with URI owl:Thing is the set of all individuals. (In DL literature this is often called the top concept.)
• The class with URI owl:Nothing is the empty set. (In DL literature this is often called the bottom concept.)

5.2 Datatypes

Datatypes are entities that refer to sets of built-in values. Thus, datatypes are analogous to classes, the main difference being that the former contain literals (such as strings and numbers) rather than individuals. Datatypes are a kind of data ranges, which allows them to be used in restrictions. All datatypes have arity one. An ontology containing a datatype with a URI that is neither rdfs:Literal nor it belongs to the datatype map (defined in Section 4) is syntactically invalid. The built-in datatype rdfs:Literal denotes any set that contains the union of the value spaces of all datatypes in the datatype map.

5.3 Object Properties

Object properties connect pairs of individuals.

URIs used to identify object properties MUST NOT be in the reserved vocabulary, apart from owl:TopObjectProperty and owl:BottomObjectProperty, which are available in OWL 2 as built-in object properties with a predefined semantics.

• The object property with URI owl:TopObjectProperty connects all possible pairs of individuals. (In DL literature this is often called the top role.)
• The object property with URI owl:BottomObjectProperty does not connect any pair of individuals. (In DL literature this is often called the bottom role.)

5.4 Data Properties

Data properties connect individuals with literals. In some knowledge representation systems, functional data properties are called attributes.

URIs used to identify data properties MUST NOT be in the reserved vocabulary, apart from owl:TopDataProperty and owl:BottomDataProperty, which are are available in OWL 2 as built-in data properties with a predefined semantics.

• The data property with URI owl:TopDataProperty connects all possible individuals with all literals. (In DL literature this is often called the top role.)
• The data property with URI owl:BottomDataProperty does not connect any individual with a literal. (In DL literature this is often called the bottom role.)

5.5 Annotation Properties

Annotation properties can be used to provide an annotation for an ontology, axiom, or an entity. The structure of annotations is further described in Section 10.

URIs used to identify annotation properties MUST NOT be in the reserved vocabulary, apart from the following URIs from the reserved vocabulary that make up the built-in annotation properties of OWL 2.

• The rdfs:label annotation property can be used to associate a human-readable label with an entity.
• The rdfs:comment annotation property can be used to associate a comment with an entity.
• The rdfs:seeAlso annotation property can be used to associate with an entity e another entity e' that provides more information about the entity e.
• The rdfs:isDefinedBy annotation property can be used to associate with an entity e another entity e' that provides information about the definition of e; the way in which this is done is not described by this specification.
• An annotation with the owl:deprecated annotation property and the value equal to "true"^^xsd:boolean can be used to specify that an entity is deprecated.
• The owl:priorVersion annotation property is described in more detail in Section 3.2.
• The owl:backwardCompatibleWith annotation property is described in more detail in Section 3.2.
• The owl:incompatibleWith annotation property is described in more detail in Section 3.2.

5.6 Individuals

Individuals represent the actual objects from the domain being modeled. There are two types of individuals in OWL 2. Named individuals are given an explicit name that can be used in any ontology in the import closure to refer to the same individual. Anonymous individuals are local to the ontology they are contained in.

5.6.1 Named Individuals

Named individuals are identified using a URI. Since they are given a URI, named individuals are entities. URIs used to identify named individuals MUST NOT be in the reserved vocabulary.

5.6.2 Anonymous Individuals

If an individual is not expected to be used outside an ontology, one can model it as an anonymous individual, which is identified by a local node ID. Anonymous individuals are analogous to blank nodes in RDF [RDF Syntax].

Special treatment is required in case anonymous individuals with the same node ID occur in two different ontologies. In particular, these two individuals are structurally equivalent (because they have the same node ID); however, they are treated as different individuals in the semantics of OWL 2 (because anonymous individuals are local to an ontology they are used in). The latter is achieved by renaming anonymous individuals apart in the axiom closure of an ontology O: when constructing the axiom closure of O, if anonymous individuals with the same node ID occur in two different ontologies in the import closure of O, then one of these individuals MUST be replaced in the respective ontology with a fresh anonymous individual (i.e., with an anonymous individual having a globally unique node ID).

5.7 Literals

Literals represent values such as particular strings or integers. They are analogous to literals in RDF [RDF Syntax] and can also be understood as individuals denoting built-in values. Each literal consists of a lexical value, which is a string, and a datatype. The datatype map determines which lexical value can be used with which datatype; an ontology containing a literal whose lexical value is not allowed by the datatype map is syntactically invalid. The datatype map also determines how the literal is mapped to the actual data value. The datatypes and literals supported in OWL 2 are described in more detail in Section 4.

Literals are generally written in the functional-style syntax as "abc"^^datatypeURI. The functional-style also supports the abbreviations for common types of text literals [RDF:TEXT]. These literals MAY equivalently be written in the original unabbreviated form; however, OWL 2 implementations are encouraged to use the abbreviated form whenever possible. These abbreviations are purely syntactic shortcuts and are thus not reflected in the structural specification of OWL 2.

• Literals of the form "abc"^^xsd:string SHOULD be abbreviated to "abc".
• Literals of the form "abc@languageTag"^^rdf:text SHOULD be abbreviated to "abc"@language.

Two literals are structurally equivalent if and only if both the lexical value and the datatype are structurally equivalent; that is, literals denoting the same data value are structurally different if either their lexical value or the datatype is different.

5.8 Referring to Entities in Functional-Style Syntax

In several places in the functional-style syntax, one needs to unambiguously refer to an entity. Since a URI can be used for several entities (of different types) at once, a URI by itself does not unambiguously identify an entity. The type of a URI is in such cases disambiguated explicitly.

5.9 Entity Declarations and Typing

Each entity u used in an OWL 2 ontology O can, and sometimes even must, be declared in O; roughly speaking, this means that the axiom closure of O must contain an appropriate declaration for u. A declaration for u in O serves two purposes:

• A declaration says that u exists — that is, it says that u is part of the vocabulary of O.
• A declaration associates with u an entity type — that is, it says whether u is a class, datatype, object property, data property, annotation property, an individual, or a combination thereof.

In OWL 2, declarations are a type of axiom; thus, to declare an entity in an ontology, one can simply include the appropriate axiom into the ontology. These axioms are nonlogical in the sense that they do not affect the model-theoretic meaning of an ontology [OWL 2 Direct Semantics]. Declarations have been defined as a kind of axiom in order to simplify the structural specification. The structure of entity declarations is shown in Figure 3.

Declarations for the built-in entities of OWL 2, listed in Table 10, are implicitly present in every OWL 2 ontology.

5.9.1 Typing Constraints

A URI u is declared to be of type T in an OWL 2 ontology O if a declaration axiom of type T for u is contained in the axiom closure of O or in the set of built-in declarations listed in Table 10. An ontology O can declare a URI u to be of more than one type, and it must declare u in certain cases; the rules governing declarations are known as typing constraints and are listed below. If O does not satisfy these typing constraints, it is syntactically invalid.

• Property typing constraints:
  • If an object property with a URI u occurs in some axiom in O, then O MUST declare u to be an object property.
  • If a data property with a URI u occurs in some axiom in O, then O MUST declare u to be a data property.
  • If an annotation property with a URI u occurs in some axiom in O, then O MUST declare u to be an annotation property.
  • A URI u MUST NOT be declared in O as being of more than one type of property; that is, u MUST NOT be declared in O to be both object and data, object and annotation, or data and annotation property.
• Class/datatype typing constraints:
  • If a class with a URI u occurs in some axiom in O, then O MUST declare u to be a class.
  • If a datatype with a URI u occurs in some axiom in O, then O MUST declare u to be a datatype.
  • A URI u MUST NOT be declared in the axiom closure of O to be both a class and a datatype.
• A declaration for a URI u MUST NOT violate the constraints on the usage of reserved vocabulary listed in the previous sections.

The typing constraints thus ensure that the sets of object, data, and annotation properties in O are disjoint and that, similarly, the sets of classes and datatypes in O are disjoint as well. These constraints are used for disambiguating the types of URIs when reading ontologies from external transfer syntaxes. All other declarations are optional.

Declarations are often omitted in the examples in this document in cases where types of entities are intuitively clear.

5.9.2 Declaration Consistency

Although declarations are optional for the most part, they can be used to catch obvious errors in ontologies.

An ontology O is said to have consistent declarations if each URI u occurring in the axiom closure of O in position of an entity with a type T is declared in O as having type T. This check applies also to the entities used in annotations; that is, these entities MUST be properly declared as well for an ontology to be structurally consistent. OWL 2 ontologies are not required to have consistent declarations: an ontology MAY be used even if its declarations are not consistent.

5.9.3 Declarations and Parsing

Ontology parsing — that is, converting an ontology written in a particular syntax into instances of the classes from the structural specification of OWL 2 — is a task that many OWL 2 tools need to support. In order to be able to instantiate the appropriate classes from the structural specification, the ontology parser sometimes needs to know the type of URIs. This typing information is extracted from declarations.

In OWL 2 there is no requirement for a declaration of an entity to physically precede the entity's usage in ontology documents; furthermore, declarations for entities can be located in imported ontologies and imports are allowed to be cyclic. In order to precisely define the result of ontology parsing, this specification defines the notion of canonical parsing. An OWL 2 parser MAY implement parsing in any way it chooses, as long as it produces a result that is structurally equivalent to the result of canonical parsing.

The result of canonical parsing of the text of an ontology O is the set of axioms obtained by the following process:

• The text of O is analyzed in order to extract the set of URIs Imp(O) of the ontologies imported in O and the set of declarations Decl(O) explicitly present in O.
• For each URI u from the set Imp(O), the text of the ontology pointed at by u is located as specified in Section 3.4, and the previous step is repeated recursively.
• Let AllDecl(O) be the set of all declarations of O, defined as the union of the set Decl(O), the sets Decl(O') for each ontology O' that is (directly or indirectly) imported into O, and the set of declarations listed in Table 10. The set AllDecl(O) is next checked for typing consistency as specified in Section 5.9.1. If any of the constraints is invalidated, the ontology O is rejected as syntactically incorrect.
• The text of O is analyzed again and the axioms of O are converted into instances of the structural specification according to the rules of the respective syntax. Declarations in AllDecl(O) are used to correctly disambiguate URI references. If O is written in the functional-style syntax, these declarations are used to disambiguate the productions for Class, Datatype, ObjectProperty, DataProperty, AnnotationProperty, and NamedIndividual.

It is important to understand that canonical parsing merely defines the result of the parsing process, and that a "smart" implementation of OWL 2 MAY optimize this process in numerous ways. In order to enable efficient parsing, OWL 2 implementations are encouraged to write ontologies into documents by placing all URI declarations before the axioms that use these URIs; however, this is not required for conformance.

In some cases, it is possible to infer the existence of missing declarations. An OWL 2 implementation MAY repair such ontologies by adding missing declarations. The precise repair process is not covered by this specification. If repair is applied, the resulting ontology MUST satisfy the typing constraints from Section 5.9.1; that is, the missing declarations MUST actually be added to the ontology.

6 Property Expressions

Properties can be used in OWL 2 to form property expressions.

6.1 Object Property Expressions

Object properties can by used in OWL 2 to form object property expressions. They are represented in the structural specification of OWL 2 by ObjectPropertyExpression, and their structure is shown in Figure 4.

As one can see from the figure, OWL 2 supports only two kinds of object property expressions. Object properties are the simplest form of object property expressions, and inverse object properties allow for bidirectional navigation in class expressions and axioms.

6.1.1 Inverse Object Properties

An inverse object property expression InverseOf( P ) connects an individual I₁ with I₂ if and only if the object property P connects I₂ with I₁.

6.2 Data Property Expressions

For symmetry with object property expressions, the structural specification of OWL 2 also introduces the notion of data property expressions, as shown in Figure 5. The only allowed data property expression is a data property; thus, DataPropertyExpression in the structural specification of OWL 2 can be seen as a place-holder for possible future extensions.

7 Data Ranges

Datatypes, such as strings or integers, can be used to express data ranges — sets of tuples of literals. Each data range is associated with a positive arity, which determines the size of the tuples in the data range. All datatypes have arity one. This specification currently does not define data ranges of arity more than one; however, by allowing for n-ary data ranges, the syntax of OWL 2 provides a "hook" for implementations allowing complex data ranges involving, for example, comparisons and arithmetic.

Data ranges can be used in restrictions on data properties, as discussed in Sections 8.4 and 8.5. The structure of data ranges in OWL 2 is shown in Figure 6. The simplest data ranges are datatypes. The DataComplementOf data range consists of all literals that are not in the specified data range. The nominal DataOneOf data range consists exactly the specified set of literals. Finally, the DatatypeRestriction data ranges are obtained by restricting the value space of a datatype by a constraining facet.

7.1 Complement of Data Ranges

A complement data range ComplementOf( DR ) contains all literals that are not contained in the data range DR.

7.2 Enumerated Data Ranges

An enumerated data range OneOf( lt₁ ... lt_n ) contains exactly the explicitly specified literals lt_i with 1 ≤ i ≤ n.

7.3 Datatype Restrictions

A datatype restriction DatatypeRestriction( DT f₁ lt₁ ... f_n lt_n ) consists of a unary datatype DT and n pairs 〈 f_i, lt_i 〉. The set of allowed constraining facets is determined by the datatype and the datatype map (see |Section 4), and the resulting unary data range denotes the subset of the value space of DT restricted according to the semantics of all 〈 f_i, lt_i 〉 (multiple pairs are interpreted conjunctively).

8 Class Expressions

In OWL 2, classes and property expressions are used to construct class expressions, sometimes also called descriptions, and, in the description logic literature, complex concepts. Class expressions represent sets of individuals by formally specifying conditions [OWL 2 Direct Semantics] on the individuals' properties; individuals satsifying these conditions are said to be instances of the respective class expressions. In the structural specification of OWL 2, class expressions are represented by ClassExpression.

OWL 2 provides a rich set of primitives that can be used to construct class expressions. In particular, it provides the well known Boolean connectives and, or, and not; a restricted form of universal and existential quantification; number restrictions; nominals; and a special self-restriction.

As shown in Figure 2, classes are the simplest form of class expressions. The other, complex, class expressions, are described in the following sections.

8.1 Propositional Connectives and Nominals

OWL 2 provides for nominals and all standard Boolean connectives, as shown in Figure 7. The ObjectIntersectionOf, ObjectUnionOf, and ObjectComplementOf class expressions provide for the standard set-theoretic operations; in logical languages these are usually called conjunction, disjunction, and negation, respectively. The nominal ObjectOneOf class expression allows for the specification of closed sets containing precisely the specified individuals.

8.1.1 Intersection

An intersection class expression IntersectionOf( CE₁ ... CE_n ) contains all individuals that are instances of all class expressions CE_i for 1 ≤ i ≤ n.

8.1.2 Union

A union class expression UnionOf( CE₁ ... CE_n ) contains all individuals that are instances of at least one class expression CE_i for 1 ≤ i ≤ n.

8.1.3 Complement

A complement class expression ComplementOf( CE ) contains all individuals that are not instances of the class expression CE.

8.1.4 Nominals

A nominal class expression OneOf( a₁ ... a_n ) contains exactly the individuals a_i with 1 ≤ i ≤ n.

8.2 Object Property Restrictions

Class expressions in OWL 2 can be formed by placing restrictions on object property expressions, as shown in Figure 8. The ObjectSomeValuesFrom class expression allows for existential quantification over an object property expression, and contains those individuals that are connected through an object property expression to an instance of a given class expression. The ObjectAllValuesFrom class expression allows for universal quantification over an object property expression, and contains those individuals that are connected through an object property expression only to instances of a given class expression. The ObjectHasValue class expression contains those individuals that are connected by an object property expression to a particular individual. Finally, the ObjectExistsSelf class expression contains those individuals that are connected by an object property expression to themselves.

8.2.1 Existential Quantification

An existential class expression SomeValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and contains all those individuals that are connected by OPE to an individual that is an instance of CE. Provided that OPE is simple according to the definition in Section 11, such a class expression can be seen as a syntactic shortcut for the class expression MinCardinality( 1 OPE CE ).

8.2.2 Universal Quantification

A universal class expression AllValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and contains all those individuals that are connected by OPE only to individuals that are instances of CE. Provided that OPE is simple according to the definition in Section 11, such a class expression can be seen as a syntactic shortcut for the class expression MaxCardinality( 0 OPE ComplementOf( CE ) ).

8.2.3 Individual Value Restrictions

A has-value class expression HasValue( OPE a ) consists of an object property expression OPE and an individual a, and contains all those individuals that are connected by OPE to a. Each such expression is equivalent to the existential restriction

8.2.4 Self-Restriction

A self-restriction ExistsSelf( PE ) consists of a property expression PE, and contains all those individuals that are connected by PE to themselves.

8.3 Object Property Cardinality Restrictions

Class expressions in OWL 2 can be formed by placing restrictions on the cardinality of object property expressions, as shown in Figure 9. All cardinality restrictions can be qualified or unqualified: the former ones require the individuals connected by an object property expression to be instances of a qualifying class expression, and the latter ones are equivalent to qualified ones with the qualifying class expression equal to owl:Thing. The class expressions ObjectMinCardinality, ObjectMaxCardinality, and ObjectExactCardinality contain those individuals that are connected by an object property expression to at least, at most, and exactly a given number of instances of a specified class expression, respectively.

8.3.1 Minimum Cardinality

A minimum cardinality expression MinCardinality( n OPE CE ) consists of a nonnegative integer n, an object property expression OPE, and a class expression CE, and it contains all those individuals that are connected by OPE to at least n different individuals that are instances of CE. If CE is missing, it is taken to be owl:Thing.

8.3.2 Maximum Cardinality

A maximum cardinality expression MaxCardinality( n OPE CE ) consists of a nonnegative integer n, an object property expression OPE, and a class expression CE, and it contains all those individuals that are connected by OPE to at most n different individuals that are instances of CE. If CE is missing, it is taken to be owl:Thing.

8.3.3 Exact Cardinality

An exact cardinality expression ExactCardinality( n OPE CE ) consists of a nonnegative integer n, an object property expression OPE, and a class expression CE, and it contains all those individuals that are connected by OPE to exactly n different individuals that are instances of CE. If CE is missing, it is taken to be owl:Thing. Such an expression is actually equivalent to the expression

8.4 Data Property Restrictions

Class expressions in OWL 2 can be formed by placing restrictions on data property expressions, as shown in Figure 10. These are similar to the restrictions on object property expressions, the main difference being that the expressions for existential and universal quantification allow for n-ary data ranges. All data ranges explicitly supported by this specification are unary; however, the provision of n-ary data ranges in existential and universal quantification allows OWL 2 tools to support extensions such as value comparisons and, consequently, class expressions such as "individuals whose width is greater than their height". Thus, the DataSomeValuesFrom class expression allows for a restricted existential quantification over a list of data property expressions, and it contains those individuals that are connected through the data property expressions to literals in the given data range. The DataAllValuesFrom class expression allows for a restricted universal quantification over a list of data property expression, and it contains those individuals that are connected through the data property expressions only to literals in the given data range. Finally, the DataHasValue class expression contains those individuals that are connected by a data property expression to a particular literal.

8.4.1 Existential Quantification

An existential class expression SomeValuesFrom( DPE₁ ... DPE_n DR ) consists of n data property expressions DPE_i, 1 ≤ i ≤ n, and an n-ary data range DR, and contains all those individuals that are connected by DPE_i to literals lt_i, 1 ≤ i ≤ n, such that the tuple 〈 lt₁, ..., lt_n 〉 is in DR. A class expression of the form SomeValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expression MinCardinality( 1 DPE DR ).

8.4.2 Universal Quantification

A universal class expression AllValuesFrom( DPE₁ ... DPE_n DR ) consists of n data property expressions DPE_i, 1 ≤ i ≤ n, and an n-ary data range DR, and contains all those individuals that are connected by DPE_i only to literals lt_i, 1 ≤ i ≤ n, such that each tuple 〈 lt₁, ..., lt_n 〉 is in DR. A class expression of the form AllValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expression MaxCardinality( 0 DPE ComplementOf( DR ) ).

8.4.3 Literal Values

A has-value class expression HasValue( DPE lt ) consists of a data property expression DPE and a literal lt, and contains all those individuals that are connected by DPE to lt. Each such expression can be seen as a syntactic abbreviation for the existential restriction

8.5 Data Property Cardinality Restrictions

Class expressions in OWL 2 can be formed by placing restrictions on the cardinality of data property expressions, as shown in Figure 11. These are similar to the restrictions on the cardinality of object property expressions. All cardinality restrictions can be qualified or unqualified: the former ones require literals connected by a data property expression to be in the qualifying data range, and the latter ones are equivalent to qualified ones with the qualifying data range equal to rdfs:Literal. The class expressions DataMinCardinality, DataMaxCardinality, and DataExactCardinality contain those individuals that are connected by a data property expression to at least, at most, and exactly a given number of literals in the specified data range, respectively.

8.5.1 Minimum Cardinality

A minimum cardinality expression MinCardinality( n DPE DR ) consists of a nonnegative integer n, a data property expression DPE, and a unary data range DR, and contains all those individuals that are connected by DPE to at least n different literals in DR. If DR is not present, it is taken to be rdfs:Literal.

8.5.2 Maximum Cardinality

A maximum cardinality expression MaxCardinality( n DPE DR ) consists of a nonnegative integer n, a data property expression DPE, and a unary data range DR, and contains all those individuals that are connected by DPE to at most n different literals in DR. If DR is not present, it is taken to be rdfs:Literal.

8.5.3 Exact Cardinality

An exact cardinality expression ExactCardinality( n DPE DR ) consists of a nonnegative integer n, a data property expression DPE, and a unary data range DR, and contains all those individuals that are connected by DPE to exactly n different literals in DR. If DR is not present, it is taken to be rdfs:Literal.

9 Axioms

OWL 2 ontologies consist of axioms — statements that say what is true in the domain being modeled. OWL 2 provides an extensive set of axioms, all of which extend the Axiom class in the structural specification.

Axioms in OWL 2 can be annotated, as described in Section 10. The annotations have no effect on the semantics of axioms — that is, they do not affect the OWL 2 meaning [OWL 2 Direct Semantics].

As shown in Figure 12, axioms in OWL 2 can be declarations, axioms about classes, axioms about object or data properties, keys, assertions (sometimes also called facts), and entity annotations.

9.1 Class Expressions Axioms

OWL 2 provides axioms that allow one to relate class expressions, as shown in Figure 13. The SubClassOf axiom allows one to state that each instance of one class expression is also an instance of another class expression, and thus to construct a hierarchy of classes. The EquivalentClasses axiom allows one to state that several class expressions are equivalent to each other. The DisjointClasses axiom allows one to state that several class expressions are disjoint with each other — that is, they have no instances in common. Finally, the DisjointUnion class expression allows one to define a class as a disjoint union of several class expressions and thus to express covering constraints.

9.1.1 Subclass Axioms

A subclass axiom SubClassOf( CE₁ CE₂ ) states that the class expression CE₁ is a subclass of the class expression CE₂. Roughly speaking, this states that CE₁ is more specific than CE₂. Subclass axioms are a fundamental type of axioms in OWL 2 and can be used to construct a class hierarchy.

9.1.2 Equivalent Classes

An equivalent classes axiom EquivalentClasses( CE₁ ... CE_n ) states that all of the class expressions CE_i, 1 ≤ i ≤ n, are semantically equivalent to each other. This axiom allows one to use each CE_i as a synonym for each CE_j — that is, in any expression in the ontology containing such an axiom, CE_i can be replaced with CE_j without affecting the meaning of the ontology. An axiom EquivalentClasses( CE₁ CE₂ ) is equivalent to the following two axioms:

Axioms of the form EquivalentClasses( C CE ), where C is a class and CE is a class expression, are often used in ontologies as definitions, because they define the class C in terms of the class expression CE.

9.1.3 Disjoint Classes

A disjoint classes axiom DisjointClasses( CE₁ ... CE_n ) states that all of the class expressions CE_i, 1 ≤ i ≤ n, are mutually disjoint with each other; that is, no individual can be at the same time an instance of both CE_i and CE_j for i ≠ j.

9.1.4 Disjoint Union of Class Expressions

A disjoint union axiom DisjointUnion( C CE₁ ... CE_n ) states that a class C is a disjoint union of the class expressions CE_i, 1 ≤ i ≤ n, all of which are mutually disjoint with each other. Such axioms are sometimes referred to as covering axioms, as they state that the extensions of all CE_i exactly cover the extension of C. Thus, each instance of C is an instance of exactly one CE_i, and each instance of CE_i is an instance of C. Each such axiom is a syntactic shortcut for the following two axioms:

9.2 Object Property Axioms

OWL 2 provides axioms that can be used to characterize object property expressions. For clarity, the structure of these axioms is shown in two separate figures, Figure 14 and Figure 15. The SubObjectPropertyOf axiom allows one to state that the extension of one object property expression is included in the extension of another object property expression. The EquivalentObjectProperties axiom allows one to state that the extensions of several object property expressions are the same. The DisjointObjectProperties axiom allows one to state that the extensions of several object property expressions are disjoint with each other — that is, they do not share pairs of connected individuals. The ObjectPropertyDomain and ObjectPropertyRange axioms can be used to restrict the first and the second individual, respectively, connected by an object property expression to be instances of the specified class expression. The InverseObjectProperties axiom can be used to state that two object property expressions are inverse of each other.

The FunctionalObjectProperty axiom allows one to state that an object property expression is functional — that is, that each individual can have at most one outgoing connection of the specified object property expression. The InverseFunctionalObjectProperty axiom allows one to state that an object property expression is inverse-functional — that is, that each individual can have at most one incoming connection of the specified object property expression. Finally, the ReflexiveObjectProperty, IrreflexiveObjectProperty, SymmetricObjectProperty, AsymmetricObjectProperty,and TransitiveObjectProperty axioms allow one to state that an object property expression is reflexive, irreflexive, symmetric, asymmetric, or transitive, respectively.

9.2.1 Object Subproperties

Object subproperty axioms are analogous to subclass axioms, and they come in two forms.

The basic form is SubPropertyOf( OPE₁ OPE₂ ). This axiom states that the object property expression OPE₁ is a subproperty of the object property expression OPE₂ — that is, if an individual x is connected by OPE₁ to an individual y, then x is also connected by OPE₂ to y.

The more complex form is SubPropertyOf( PropertyChain( OPE₁ ... OPE_n ) OPE ). This axiom states that if an individual x is connected by a sequence of object property expressions OPE₁, ..., OPE_n with an individual y then x is also connected with y by the object property expression OPE. Such axioms are also known as complex role inclusions [SROIQ].

9.2.2 Equivalent Object Properties

An equivalent object properties axiom EquivalentProperties( OPE₁ ... OPE_n ) states that all of the object property expressions OPE_i, 1 ≤ i ≤ n, are semantically equivalent with each other. This axiom allows one to use each OPE_i as a synonym for each OPE_j — that is, in any expression in the ontology containing such an axiom, OPE_i can be replaced with OPE_j without affecting the meaning of the ontology. The axiom EquivalentProperties( OPE₁ OPE₂ ) is equivalent to the following two axioms:

9.2.3 Disjoint Object Properties

A disjoint object properties axiom DisjointProperties( OPE₁ ... OPE_n ) states that all of the object property expressions OPE_i, 1 ≤ i ≤ n, are mutually disjoint with each other; that is, no pair of individuals 〈 x, y 〉 can at the same time be connected by both OPE_i and OPE_j for i ≠ j.

9.2.4 Object Property Domain

An object property domain axiom PropertyDomain( OPE CE ) states that the domain of the object property expression OPE is the class expression CE — that is, if an individual x is connected by OPE with some other individual, then x is an instance of CE. This axiom can be seen as equivalent to the following axiom:

9.2.5 Object Property Range

An object property range axiom PropertyRange( OPE CE ) states that the range of the object property expression OPE is the class expression CE — that is, if some individual is connected by OPE with an individual x, then x is an instance of CE. This axiom can be seen as equivalent to the following axiom:

9.2.6 Inverse Object Properties

An inverse object properties axiom InverseProperties( OPE₁ OPE₂ ) states that the object property expression OPE₁ is an inverse of the object property expression OPE₂. Thus, if an individual x is connected by OPE₁ with an individual y, then y is also connected by OPE₂ with x, and vice versa. This axiom can be seen as equivalent to the following axiom:

9.2.7 Functional Object Properties

An object property functionality axiom FunctionalProperty( OPE ) states that the object property expression OPE is functional — that is, for each individual x, there can be at most one distinct individual y such that x is connected by OPE to y. This axiom can be seen as equivalent to the following axiom:

9.2.8 Inverse-Functional Object Properties

An object property inverse functionality axiom InverseFunctionalProperty( OPE ) states that the object property expression OPE is inverse-functional — that is, for each individual x, there can be at most one individual y such that y is connected by OPE with x. This axiom can be seen as a syntactic shortcut for the following axiom:

9.2.9 Reflexive Object Properties

An object property reflexivity axiom ReflexiveProperty( OPE ) states that the object property expression OPE is reflexive — that is, each individual is connected by OPE to itself.

9.2.10 Irreflexive Object Properties

An object property irreflexivity axiom IrreflexiveProperty( OPE ) states that the object property expression OPE is irreflexive — that is, no individual is connected by OPE to itself.

9.2.11 Symmetric Object Properties

An object property symmetry axiom SymmetricProperty( OPE ) states that the object property expression OPE is symmetric — that is, if an individual x is connected by OPE to an individual y, then y is also connected by OPE to x. This axiom can be seen as equivalent to the axiom

9.2.12 Asymmetric Object Properties

An object property asymmetry axiom AsymmetricProperty( OPE ) states that the object property expression OPE is asymmetric — that is, if an individual x is connected by OPE to an individual y, then y cannot be connected by OPE to x.

9.2.13 Transitive Object Properties

An object property transitivity axiom TransitiveProperty( OPE ) states that the object property expression OPE is transitive — that is, if an individual x is connected by OPE to an individual y that is connected by OPE to an individual z, then x is also connected by OPE to z. This axiom can be seen as equivalent to the axiom

9.3 Data Property Axioms

OWL 2 also provides for data property axioms. Their structure is similar to object property axioms, as shown in Figure 16. The SubDataPropertyOf axiom allows one to state that the extension of one data property expression is included in the extension of another data property expression. The EquivalentDataProperties allows one to state that several data property expressions have the same extension. The DisjointDataProperties axiom allows one to state that the extensions of several data property expressions are disjoint with each other — that is, they do not share individual–literal pairs. The DataPropertyDomain axiom can be used to restrict individuals connected by a property expression to be instances of the specified class; similarly, the DataPropertyRange axiom can be used to restrict the literals pointed to by a property expression to be in the specified data range. Finally, the FunctionalDataProperty axiom allows one to state that a data property expression is functional — that is, that each individual can have at most one outgoing connection of the specified data property expression.

Note that the arity of the data range used in a DataPropertyRange axiom MUST be one.

9.3.1 Data Subproperties

A data subproperty axiom SubPropertyOf( DPE₁ DPE₂ ) states that the data property expression DPE₁ is a subproperty of the data property expression DPE₂ — that is, if an individual x is connected by OPE₁ with a literal y, then x is connected by OPE₂ with y as well.

9.3.2 Equivalent Data Properties

An equivalent data properties axiom EquivalentProperties( DPE₁ ... DPE_n ) states that all the data property expressions DPE_i, 1 ≤ i ≤ n, are semantically equivalent to each other. This axiom allows one to use each DPE_i as a synonym for each DPE_j — that is, in any expression in the ontology containing such an axiom, DPE_i can be replaced with DPE_j without affecting the meaning of the ontology. The axiom EquivalentProperties( DPE₁ DPE₂ ) can be understood as equivalent to the following two axioms:

9.3.3 Disjoint Data Properties

A disjoint data properties axiom DisjointProperties( DPE₁ ... DPE_n ) states that all of the data property expressions DPE_i, 1 ≤ i ≤ n, are mutually disjoint with each other; that is, no individual x can at the same time be connected with some literal y through both DPE_i and DPE_j for i ≠ j.

9.3.4 Data Property Domain

A data property domain axiom PropertyDomain( DPE CE ) states that the domain of the data property expression DPE is the class expression CE — that is, if an individual x is connected by DPE with some literal, then x is an instance of CE. Each such axiom is equivalent to the following axiom:

9.3.5 Data Property Range

A data property range axiom PropertyRange( DPE DR ) states that the range of the data property expression DPE is the data range DR — that is, if some individual is connected by DPE with a literal x, then x is in DR. Each such axiom is equivalent to the following axiom:

9.3.6 Functional Data Properties

A data property functionality axiom FunctionalProperty( DPE ) states that the data property expression DPE is functional — that is, for each individual x, there can be at most one distinct literal y such that x is connected by DPE with y. Each such axiom is equivalent to the following axiom:

9.4 Keys

A key axiom HasKey( CE PE₁ ... PE_n ) states that each (named) instance of the class expression CE is uniquely identified by the (data or object) property expressions PE_i — that is, no two distinct (named) instances of CE can coincide on the values of all property expressions PE_i. A key axiom of the form HasKey( owl:Thing OPE ) is similar to the axiom InverseFunctionalProperty( OPE ); the main difference is that the first axiom is applicable only to individuals that are explicitly named in an ontology, while the second axiom is also applicable to individuals whose existence is implied by existential quantification. The structure of such axiom is shown in Figure 17.

The semantics of key axioms is specific in that these axioms apply only to individuals explicitly introduced in the ontology by name, and not to unnamed individuals (i.e., the individuals whose existence is implied by existential quantification). This makes key axioms equivalent to a variant of DL-safe rules [DL-Safe]. Thus, key axioms will typically not affect class-based inferences such as the computation of the subsumption hierarchy, but they will play a role in answering queries about individuals. This choice has been made in order to keep the language decidable.

9.5 Assertions

OWL 2 supports a rich set of axioms for stating assertions — axioms about individuals that are often also called facts. For clarity, different types of assertions are shown in three separate figures, Figure 18, 19, and 20. The SameIndividual assertion allows one to state that several individuals are all equal to each other, while the DifferentIndividuals assertion allows for the opposite — that is, to state that several individuals are all different from each other. The ClassAssertion axiom allows one to state that an individual is an instance of a particular class.

The ObjectPropertyAssertion axiom allows one to state that an individual is connected by an object property expression to an individual, while NegativeObjectPropertyAssertion allows for the opposite — that is, to state that an individual is not connected by an object property expression to an individual.

The DataPropertyAssertion axiom allows one to state that an individual is connected by a data property expression to literal, while NegativeDataPropertyAssertion allows for the opposite — that is, to state that an individual is not connected by a data property expression to a literal.

9.5.1 Individual Equality

An individual equality axiom SameIndividual( a₁ ... a_n ) states that all of the individuals a_i, 1 ≤ i ≤ n, are equal to each other. This axiom allows one to use each a_i as a synonym for each a_j — that is, in any expression in the ontology containing such an axiom, a_i can be replaced with a_j without affecting the meaning of the ontology.

9.5.2 Individual Inequality

An individual inequality axiom DifferentIndividuals( a₁ ... a_n ) states that all of the individuals a_i, 1 ≤ i ≤ n, are mutually different from each other; that is, no individuals a_i and a_j with i ≠ j can be derived to be equal. This axiom can be used to axiomatize the unique name assumption — the assumption that all different individual names denote different individuals.

9.5.3 Class Assertions

A class assertion ClassAssertion( CE a ) states that the individual a is an instance of the class expression CE.

9.5.4 Positive Object Property Assertions

A positive object property assertion PropertyAssertion( OPE a₁ a₂ ) states that the individual a₁ is connected by the object property expression OPE to the individual a₂.

9.5.5 Negative Object Property Assertions

A negative object property assertion NegativePropertyAssertion( OPE a₁ a₂ ) states that the individual a₁ is not connected by the object property expression OPE to the individual a₂.

9.5.6 Positive Data Property Assertions

A positive data property assertion PropertyAssertion( DPE a lt ) states that the individual a is connected by the data property expression DPE to the literal lt.

9.5.7 Negative Data Property Assertions

A negative data property assertion NegativePropertyAssertion( DPE a lt ) states that the individual a is not connected by the data property expression DPE to the literal lt.

10 Annotations

OWL 2 applications often need ways to associate information with ontologies, entities, and axioms in a way that does not affect the logical meaning of the ontology. Such information often plays a central role in OWL 2 applications. Although such information is not expected to affect the formal meaning of an ontology (i.e., it is not expected to affect the set of logical consequences that one can derive from an ontology), it is expected to be accessible in the structural specification of OWL 2. To this end, OWL 2 provides for annotations on ontologies, axioms, and entities.

Certain OWL 2 provide a mechanism for embedding comments into ontology documents. The structure of such comments, however, is dependent on the syntax, so representing them in the structural specification is likely to be difficult or even impossible; hence, such comments are simply discarded during parsing. In contrast, annotations are "first-class citizens" in the structural specification of OWL 2, and their structure is independent of the underlying syntax.

10.1 Annotation Values

An annotation consists of an annotation property and a value for the annotation. OWL 2 allows for three kinds of annotation values, as shown in Figure 21.

• Annotation values can be literals. Note that these need not be just strings; rather, any OWL 2 literal can be used.
• Annotation values can be ontology entities. Such annotations make it clearer that the value is not just some literal, but an entity from this or some other ontology.
• Annotation values can be anonymous individuals.

The functional-style syntax for OWL 2 provides an abbreviation mechanism for annotations with the common rdfs:label and rdfs:comment annotation properties, and for abbreviating annotations of the form Annotation( owl:deprecated "true"^^xsd:boolean ). These are purely syntactic abbreviations and are not reflected in the structural specification of OWL 2.

10.2 Annotations of Axioms and Ontologies

Annotations can be associated with axioms and ontologies, as shown in Figure 1. Annotations on axioms and ontologies affect their structural equivalence. Thus, for two axioms to be structurally equivalent, the annotations on them MUST be structurally equivalent as well, and similarly for ontologies. Since annotations are embedded into ontologies and axioms, the syntax for annotating them has been presented in the previous sections of this document.

10.3 Annotations of Entities and Anonymous Individuals

Annotations are attached to entities and anonymous individuals using entity and anonymous individual annotation axioms, shown in Figure 22. Such axioms do not affect the semantics of an OWL 2 ontology, and they are made axioms in order to simplify the structural specification of OWL 2. Each such axiom provides for two types of annotations — one for the axiom itself and one for the entity. It is important to distinguish these two types of annotation: the first one refers to the axiom (e.g., it says who has asserted it), whereas the second one refers to the entity/anonymous individual itself (e.g., it provides a human-friendly label).

11 Global Restrictions on Axioms

Let Ax be the axiom closure (with anonymous individuals renamed apart as explained in Section 5.6.2) of an OWL 2 ontology O. As explained in the literature [SROIQ], Ax MUST obey certain global restrictions in order to obtain a decidable language. The formal definition of these restrictions is rather technical, so it is split into two parts. Section 11.1 first introduces the notions of a property hierarchy and of simple object property expressions. These notions are then used in Section 11.2 to define the actual restrictions on the axioms in the axiom closure of an ontology.

11.1 Property Hierarchy and Simple Object Property Expressions

For an object property expression OPE, the inverse property expression INV(OPE) is defined as follows:

• If OPE is an object property OP, then INV(OPE) = InverseOf( OP ).
• if OPE is of the form InverseOf( OP ) for OP an object property, then INV(OPE) = OP.

The set AllOPE(Ax) of all object property expressions w.r.t. Ax is the smallest set containing OP and INV(OP) for each object property OP occurring in Ax.

An object property expression OPE is composite in the set of axioms Ax if

• OPE is equal to owl:TopObjectProperty or owl:BottomObjectProperty, or
• Ax contains an axiom of the form
  • SubPropertyOf( PropertyChain( OPE₁ ... OPE_n ) OPE ) with n > 1, or
  • SubPropertyOf( PropertyChain( OPE₁ ... OPE_n ) INV(OPE) ) with n > 1, or
  • TransitiveProperty( OPE ), or
  • TransitiveProperty( INV(OPE) ).

The relation → is the smallest relation on AllOPE(Ax) for which the following conditions hold (A → B means that → holds for A and B):

• if Ax contains an axiom SubPropertyOf( OPE₁ OPE₂ ), then OPE₁ → OPE₂ holds; and
• if Ax contains an axiom EquivalentProperties( OPE₁ OPE₂ ), then OPE₁ → OPE₂ and OPE₂ → OPE₁ hold; and
• if Ax contains an axiom InverseProperties( OPE₁ OPE₂ ), then OPE₁ → INV(OPE₂) and INV(OPE₂) → OPE₁ hold; and
• if Ax contains an axiom SymmetricProperty(OPE), then OPE → INV(OPE) holds; and
• if OPE₁ → OPE₂ holds, then INV(OPE₁) → INV(OPE₂) holds as well.

The property hierarchy relation →^* is the reflexive-transitive closure of →.

An object property expression OPE is simple in Ax if, for each object property expression OPE' such that OPE' →^* OPE holds, OPE' is not composite.

11.2 The Restrictions on the Axiom Closure

The axioms Ax satisfy the global restrictions of OWL 2 if the following six conditions hold:

• Each class expression in Ax of type from the following list contains only simple object property expressions:
  • MinObjectCardinality, MaxObjectCardinality, ExactObjectCardinality, and ObjectExistsSelf .
• Each axiom in Ax of type from the following list contains only simple object property expressions:
  • FunctionalObjectProperty, InverseFunctionalObjectProperty, IrreflexiveObjectProperty, AsymmetricObjectProperty, and DisjointObjectProperties.
• No SubObjectPropertyOf axiom in Ax contains the owl:TopObjectProperty property, and no SubDataPropertyOf axiom in Ax contains the owl:TopDataProperty property.
• A strict partial order (i.e., an irreflexive and transitive relation) < on AllOPE(Ax) exists that fulfills the following conditions:
  • OP₁ < OP₂ if and only if INV(OP₁) < OP₂ for all object properties OP₁ and OP₂ occurring in AllOPE(Ax).
  • If OPE₁ < OPE₂ holds, then OPE₂ →^* OPE₁ does not hold;
  • Each axiom in Ax of the form SubPropertyOf( PropertyChain( OPE₁ ... OPE_n ) OPE ) with n ≥ 2 fulfills the following conditions:
    • n = 2 and OPE₁ = OPE₂ = OPE, or
    • OPE_i < OPE for each 1 ≤ i ≤ n, or
    • OPE₁ = OPE and OPE_i < OPE for each 2 ≤ i ≤ n, or
    • OPE_n = OPE and OPE_i < OPE for each 1 ≤ i ≤ n-1.
• No axiom in Ax of the following form contains anonymous individuals:
  • SameIndividual, DifferentIndividuals, NegativeObjectPropertyAssertion, and NegativeDataPropertyAssertion.
• A forest F over the anonymous individuals in Ax exists such that, for each axiom in Ax of the form PropertyAssertion( P a₁ a₂ ) with P an object property and a₁ and a₂ anonymous individuals, either a₁ is a child of a₂ in F or a₂ is a child of a₁ in F.

12 Appendix: Differences from OWL 1 Abstract Syntax

OWL 2 departs in its conceptual design and in syntax from OWL 1 Abstract Syntax. This section summarizes the major differences and explains the rationale behind the changes.

12.1 Dropping the Frame-Like Syntax

OWL 1 provides a frame-like syntax that allows several aspects of a class, property or individual to be defined in a single axiom.

This type of axiom may cause problems in practice. First, it bundles many different features of the given entity into a single axiom. While this may be convenient when ontologies are being manipulated by hand, it is not convenient for manipulating them programmatically. In fact, most implementations of OWL 1 break such axioms apart into several "atomic" axioms, each dealing with only a single feature of the entity. However, this may cause problems with round-tripping, as the structure of the ontology may be destroyed in the process. Second, this type of axiom is often misinterpreted as a declaration and unique "definition" of the given entity. In OWL 1, however, entities may be used without being the subject of any such axiom, and there may be many such axioms relating to the same entity. Third, OWL 1 does not provide means to annotate axioms, which has proved to be quite useful in practice. These problems are addressed in OWL 2 in several ways. First, the frame-like notation has been dropped in favor of a more fine-grained structure of axioms, where each axiom describes just one feature of the given entity. Second, OWL 2 provides explicit declarations, and an explicit definition of the notion of structural consistency. Third, all axioms in OWL 2 can be annotated, and entity annotation axioms provide means for that.

Although OWL 2 is more verbose, this is not expected to lead to problems given that most OWL ontologies are created using ontology engineering tools. Moreover, such tools are free to present the information to the user in a more intuitive (possibly frame-like) way.

12.2 Inverse Property Expressions

In OWL 1, all properties are atomic, but it is possible to assert that one object property is the inverse of another.

In OWL 2, property expressions such as InverseOf( a:hasPart ) can be used in class expressions, which avoids the need to give a name to every inverse property. If desired, however, names can still be given to inverse properties.

13 Complete Grammar (Normative)

14 Index

15 References

[OWL 2 Direct Semantics]

OWL 2 Web Ontology Language: Direct Semantics. Bernardo Cuenca Grau and Boris Motik, eds., 2008.

[OWL 2 XML Syntax]

OWL 2 Web Ontology Language: XML Serialization. Bernardo Cuenca Grau, Boris Motik, and Peter. F. Patel-Schneider, eds., 2008.

[SROIQ]

The Even More Irresistible SROIQ. Ian Horrocks, Oliver Kutz, and Uli Sattler. In Proc. of the 10th Int. Conf. on Principles of Knowledge Representation and Reasoning (KR 2006). AAAI Press, 2006.

[XML]

Extensible Markup Language (XML) 1.1. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, John Cowan, eds. W3C Recommendation 16 August 2006, edited in place 29 September 2006.

[XML Namespaces]

Namespaces in XML 1.0 (Second Edition). Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin, eds. W3C Recommendation 16 August 2006.

[XML Schema Datatypes]

XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, eds. W3C Recommendation 28 October 2004.

[RDF Syntax]

RDF/XML Syntax Specification (Revised). Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/rdf-syntax-grammar/.

[BCP 47]

BCP 47 - Tags for Identifying Languages. A. Phillips, M. Davis, eds., IETF, September 2006, http://www.rfc-editor.org/rfc/bcp/bcp47.txt.

[RFC 3987]

RFC 3987 - Internationalized Resource Identifiers (IRIs). M. Duerst, M. Suignard. IETF, January 2005, http://www.ietf.org/rfc/rfc3987.txt.

[RFC 2119]

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Network Working Group, S. Bradner. Internet Best Current Practice, March 1997.

[OWL Semantics and Abstract Syntax]

OWL Web Ontology Language: Semantics and Abstract Syntax Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, eds. W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/. Latest version available at http://www.w3.org/TR/owl-semantics/.

[CURIE]

CURIE Syntax 1.0: A syntax for expressing Compact URIs. M. Birbeck, S. McCarron, Editors, W3C Working Draft, 26 November 2007, http://www.w3.org/TR/2007/WD-curie-20071126/.

[RDF Test Cases]

RDF Test Cases. Jan Grant and Dave Beckett, Editors, W3C Recommendation 10 February 2004, http://www.w3.org/TR/rdf-testcases/.

[ISO/IEC 10646]

ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. ISO (International Organization for Standardization).

[DL-Safe]

Query Answering for OWL-DL with Rules. Boris Motik, Ulrike Sattler, and Rudi Studer. Journal of Web Semantics: Science, Services and Agents on the World Wide Web, 3(1):41–60, 2005.

[IEEE 754]

IEEE Standard for Binary Floating-Point Arithmetic. Standards Committee of the IEEE Computer Society

[ISO 8601:2004]

ISO 8601:2004. Representations of dates and times. ISO (International Organization for Standardization).

[RDF:TEXT]

A Datatype for Internationalized Text. Jie Bao and Axel Polleres, eds., W3C Draft