Syntax

Authors

Boris Motik, Oxford University

Peter F. Patel-Schneider, Bell Labs Research, Alcatel-Lucent

Ian Horrocks, Oxford University

[Show Short TOC]

[Show Full TOC]

1 Introduction

This document defines the OWL 2 language. The core part of this specification is independent of the concrete exchange syntaxes for OWL 2 ontologies, as the language is defined by describing the conceptual structure of OWL 2 ontologies. 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. For example, 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.

Conceptually, OWL 2 ontologies are built from and using 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. 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 are descriptive characterizations of entities. For example, a class expression defines a class in terms of the features that its instances must exhibit.
• 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 ontologies can be large, so 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 additional features, 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 behaviour 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 Semantics].

In several places, this document uses the keywords SHOULD and SHOULD NOT to specify certain aspects of normative behavior of OWL 2 tools [KEYWORDS].

• OWL 2 tools are expected to obey the restrictions specified using SHOULD and SHOULD NOT.
• An OWL 2 tool can choose to deviate from the expected behavior specified using SHOULD and SHOULD NOT. If clearly documented, such deviation does not constitute an infringement of the normative specification.

2 Basic Definitions

The structural specification of OWL 2 is defined using the Unified Modeling Language (UML). 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.

The OWL 2 functional-style syntax is presented using standard BNF notation. Nonterminal symbols are written in bold (e.g., ClassExpression), terminal symbols are written in single quotes (e.g. 'PropertyRange'), zero or more instances of a symbol are denoted with curly braces (e.g., { ClassExpression }), alternative productions are denoted with the vertical bar (e.g., Assertion | Declaration), and zero or one instances of a symbol are denoted with square brackets (e.g., [ ClassExpression ]). Documents containing OWL 2 ontologies written in functional-style syntax SHOULD use the UTF-8 encoding.

2.1 Associations and Structural Equivalence

Many associations between components of OWL 2 ontologies are of one-to-many type; for example, an ObjectUnionOf class expression contains a set of disjuncts. Whether the components in the association are ordered and whether repetitions are allowed is made clear by the 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 names of associations that are ordered and in which repetitions are allowed. Such associations have the semantics of lists.

Whether two ontology components are considered to be the same is captured by the notion of structural equivalence, defined as follows. Components o₁ and o₂ are structurally equivalent 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 equal using equality for their atomic type — that is, if they are the same string, integer, or IRI.
• 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 components composed of other components, they are structurally equivalent if
  • both o₁ and o₂ are of the same type,
  • each component of o₁ is structurally equivalent to the corresponding component of o₂, and
  • each association of o₁ is structurally equivalent to the corresponding association of o₂.

For example, the class expression UnionOf( a:Person a:Animal ) is structurally equivalent to the class expression UnionOf( a:Animal a:Person ) because the order of the elements in an unordered association is not important. Note that structural equivalence is not a semantic notion, as it is based only on comparing object structures. For example, UnionOf( a:Person ComplementOf( a:Person ) ) is not structurally equivalent to owl:Thing even though they are semantically equivalent. Defining the structure of the language using sets facilitates the specification of APIs for manipulating OWL 2 ontologies programmatically, and it provides the basis for the definition of complex operations on OWL 2 ontologies, such as retraction of axioms.

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; for example, an ontology written in functional-style syntax can contain a class expression of the form UnionOf( a:Person a:Animal a:Animal ). Duplicates SHOULD be eliminated from such constructs during parsing.

2.2 URIs and Namespaces

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

CURIEs [CURIE] are used for abbreviating long IRIs.

IRIs can either be given in full, or they can be abbreviated using CURIEs.

Abbreviated IRIs are turned into full IRIs by looking up the value matched to the prefix production in the namespace definitions associated with an ontology and concatenating the associated full-IRI value with the value matched to reference in the abbreviated-IRI production. The result must be a valid IRI. Abbreviated IRIs with no prefix are handled by the namespace definition with no prefix.

Table 1 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 2 have special treatment in OWL 2. All other URIs from the reserved vocabulary constitute the disallowed vocabulary of OWL 2 and are not to be used in OWL 2 ontologies.

2.3 Integers, Strings, Language Tags, and Node IDs

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

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]. Just like in XML Schema Datatypes [XML Schema Datatypes], a character must match the Char production from XML [XML]. Since the set of UCS characters is continually evolving, in OWL 2 it is assumed that the set of available characters is infinite, as this makes the semantics of the language independent from the 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 enclosed in double quotes; in order to allow for strings that contain the quotation character, OWL 2 employs a quoting mechanism that is a subset of the one used in the N-triples specification [RDF Test Cases].

Language tags are nonempty strings as defined in RFC-4646 [RFC-4646]. In functional-style syntax, language tags are not enclosed in double quotes; this does not lead to parsing problems since, according to RDF-4646, language tags do not contain whitespace.

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, however, not expected to enforce this: when reading OWL 2 ontologies stored in documents, an OWL 2 implementation can simply 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 can exist for a given prefix. These prefixes are then used to expand abbreviated IRIs as specified in Section 2.2.

3.1 Ontology URI and Version URI

Each ontology can have an ontology URI, which is used to identify an ontology. If an ontology has an ontology URI, the ontology can additionally have a version URI, which is used to identify the version of the ontology. The version URI can, but need not be equal to the ontology URI. An ontology without an ontology URI cannot 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. For example, two different ontologies are allowed to have no ontology URI and no version URI; similarly, an ontology containing only an ontology URI can 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 can 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. The structural specification does NOT explicitly contain an object corresponding to the ontology series; therefore, an ontology series is an informal term that 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, 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 must 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 can 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 a set of 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 imports 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 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 nonlogical information with an ontology, such as the name of the ontology creator or the version of the ontology. 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; rather, their values can be used by OWL 2, for example, for managing information about an ontology.

OWL 2 provides several built-in annotation properties for annotating ontologies. 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. The set N_DT must not contain 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 should be clear from the context. A literal for a datatype DT has the form "abc"^^DT, where abc is a string called the lexical representation of the literal.
• N_FA is a function that assigns to each datatype DT ∈ N_DT a set N_FA(DT) of facet–literal pairs of the form < f lt > where 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 facet–literal 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 must thus 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" should 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 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 3, for representing various kinds of numbers.

Value Spaces. The value spaces of all numeric datatypes are shown in Table 3. 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.

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.

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 representation 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 the absolute value less than 10¹⁶ and the representation of the number requires at most 16 digits in total.

Equality and Ordering. The facets 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.

Facets. Each numeric datatype DT supports all facet–literal pairs of the form < f lt > where f is minInclusive, maxInclusive, minExclusive, or maxExclusive, and lt is a literal of a (possibly different) numeric datatype. The value of each such facet–literal pair is defined in Table 4.

4.2 Strings

4.2.1 Strings with a Language Tag

The owl:internationalizedString datatype allows for the representation of strings in a particular language.

Value Space. The value space of owl:internationalizedString is a set of pairs of strings the form < "abc" , "tag" >, where "abc" is an arbitrary string, and "tag" is either the empty string or a language tag as defined in Section 2.3.

Literals. The owl:internationalizedString datatype supports literals of the form "rep"^^owl:internationalizedString, where "rep" is a string that contains at least one character @. For a literal "rep"^^owl:internationalizedString, let i be the position of the last character @ in "rep"; then, this literal is assigned a value < "abc", "tag" > where "abc" is the string of characters of "rep" up to (but not including) position i, and "abc" is the string of characters of "rep" after (but not including) position i.

Facets. The owl:internationalizedString datatype supports the facets shown in Table 5.

4.2.2 Strings without a Language Tag

XML Schema Datatypes [XML Schema Datatypes] provides the following datatypes for the representation of strings:

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

In XML Schema, xsd:string is the basic datatype for the representation of unrestricted strings. All other datatypes impose restrictions on the structure of strings; in all cases, these restrictions can be represented by a regular expression.

All of these datatypes are available in OWL 2 as well, with a minor change in the definition of the value space. This change ensures that the value spaces of all these datatypes are subsets of the value space of owl:internationalizedString.

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

Facets. Each datatype DT from the above list supports the facets minLength, maxLength, length, and pattern. The facet value of each facet–value pair for DT is the same as in Table 5, with the difference that the result is a subset of (DT)^DT instead of (owl:internationalizedString)^DT.

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.

Facets. The xsd:boolean datatype does not support any 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].

Facets. Datatypes xsd:hexBinary and xsd:base64Binary support facets that are shown in Table 6.

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 the literals of the form "abc"^^xsd:anyURI where "abc" is a string as specified 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.

Facets. The xsd:anyURI datatype supports the facets shown in Table 7.

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 set 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 should be ignored, and single quites should be understood as introducing 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 syntax for timezone can have one of the following forms, and it 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 must be between 1 and 12 (inclusive).
• day must be 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 must 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.

The literals of owl:dateTime can represent an arbitrary date. An OWL 2 implementation may support all of 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.

Facets. The owl:dateTime datatype supports the facets shown in Table 8.

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; datatype 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 representation 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 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. A URI used to refer to a datatype can either be rdfs:Literal or it must belong to the datatype map (Section 4); an ontology violating this requirement 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 associate 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 associate 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 "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. OWL 2 provides two types of individuals. Named individuals are given an explicit name that can be used in any ontology. 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 representation, which is a string, and a datatype. The datatype map determines which lexical representation can be used with which datatype; an ontology containing a literal whose lexical representation is not allowed by the datatype map is syntactically invalid. The datatype map also determines how the literal is mapped to the actual 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 syntax provides for two abbreviations for writing certain common types of literals. These literals can equivalently be written in the original unabbreviated form; however, OWL 2 implementations are encouraged to use the abbreviated form whenever possible. These abbreviations should be understood purely as syntactic shortcuts and are thus not reflected in the structural specification of OWL 2.

• Literals of the form "abc"^^xsd:string can be abbreviated to "abc".
• Literals of the form "abc@languageTag"^^owl:internationalizedString can be abbreviated to "abc"@language.

Two literals are structurally equivalent if and only if both the lexical representation and the datatype are structurally equivalent; that is, literals denoting the same value can be structurally different if either their lexical representation 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. For example, an ontology editor can use declarations to implement functions such as "Add New Class".
• 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.

For example, an ontology might contain a declaration for the URI a:Person and state that this URI is a class. Such a declaration states that a:Person exists in the ontology and it determines the type of the URI as being a class.

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 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 9, 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 9. 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 an 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.
  • Each URI u can be declared in the axiom closure of O as being of at most one type of property; that is, u cannot 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 cannot be declared in the axiom closure of O to be both a class and a datatype.
• No declaration for a URI u can 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; for example, a URI u can be used as an individual in O even if u is not declared as an individual in O.

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