OWL 2 Web Ontology Language
Structural Specification and Functional-Style Syntax (Second Edition)

W3C Recommendation 11 December 2012

This version:

http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/

Latest version (series 2):

http://www.w3.org/TR/owl2-syntax/

Latest Recommendation:

http://www.w3.org/TR/owl-syntax

Previous version:

http://www.w3.org/TR/2012/PER-owl2-syntax-20121018/

Editors:

Boris Motik, University of Oxford

Peter F. Patel-Schneider, Nuance Communications

Bijan Parsia, University of Manchester

Contributors: (in alphabetical order)

Conrad Bock, National Institute of Standards and Technology (NIST)

Achille Fokoue, IBM Corporation

Peter Haase, FZI Research Center for Information Technology

Rinke Hoekstra, University of Amsterdam

Ian Horrocks, University of Oxford

Alan Ruttenberg, Science Commons (Creative Commons)

Uli Sattler, University of Manchester

Michael Smith, Clark & Parsia

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

A color-coded version of this document showing changes made since the previous version is also available.

This document is also available in these non-normative formats: PDF version.

See also translations.

Copyright © 2012 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Summary of Changes

Please Send Comments

Please send any comments to [email protected] (public archive). Although work on this document by the OWL Working Group is complete, comments may be addressed in the errata or in future revisions. Open discussion among developers is welcome at [email protected] (public archive).

Endorsed By W3C

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent.

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. The structural specification describes the conceptual structure of OWL 2 ontologies and thus provides a normative abstract representation 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. Each OWL 2 ontology represented as an instance of this conceptual structure can be converted into an RDF graph [OWL 2 RDF Mapping]; conversely, most OWL 2 ontologies represented as RDF graphs can be converted into the conceptual structure defined in this document [OWL 2 RDF Mapping].

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 used in the definitions of the semantics of OWL 2 ontologies, the mappings from and into the RDF/XML exchange syntax, and the different profiles of OWL 2. Concrete syntaxes, such as the functional-style syntax, often provide features not found in the structural specification, such as a mechanism for abbreviating IRIs.

Finally, this document defines OWL 2 DL — the subset of OWL 2 with favorable computational properties. Each RDF graph obtained by applying the RDF mapping to an OWL 2 DL ontology can be converted back into the conceptual structure defined in this document by means of the reverse RDF mapping [OWL 2 RDF Mapping].

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

• Entities, such as classes, properties, and individuals, are identified by IRIs. They form the primitive terms of an ontology and constitute the basic elements of an ontology. For example, a class a:Person can be used to represent the set of all people. Similarly, the object property a:parentOf can be used to represent the parent-child relationship. Finally, the individual a:Peter can be used to represent a particular person called "Peter".
• Expressions represent complex notions in the domain being described. For example, a class expression describes a set of individuals in terms of the restrictions on the individuals' characteristics.
• Axioms are statements that are asserted to be true in the domain being described. 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 useful inferences to be drawn. 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 from the OWL 2 semantics one can derive that a:Peter is also 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 a more descriptive 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 might choose to visualize a class using one of its labels.

Finally, 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'.

This document defines the structural specification of OWL 2, the functional syntax for OWL 2, the behavior of datatype maps, and OWL 2 DL. 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 identified as informative is not normative. Further, the informal descriptions of the semantics of OWL 2 constructs in this document are informative; the Direct Semantics [OWL 2 Direct Semantics] and the RDF-Based [OWL 2 RDF-Based Semantics] are precisely specified in separate documents.

The italicized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used to specify normative features of OWL 2 documents and 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 Structural Specification

The structural specification of OWL 2 consists of all the figures in this document and the notion of structural equivalence given below. It is used throughout this document to precisely specify the structure of OWL 2 ontologies and the observable behavior of OWL 2 tools. An OWL 2 tool MAY base its APIs and/or internal storage model on the structural specification; however, it MAY also choose a completely different approach as long as its observable behavior conforms to the one specified in this document.

The structural specification is defined using the Unified Modeling Language (UML) [UML], and the notation used is compatible with the Meta-Object Facility (MOF) [MOF]. This document uses only a very simple form of UML class diagrams that are expected to be easily understandable by readers familiar with the basic concepts of object-oriented systems. The following list summarizes the UML notation used in this document.

• The names of the UML classes from the structural specification are written in bold font.
• The names of abstract UML classes (i.e., UML classes that are not intended to be instantiated) are written in bold and italic font.
• Instances of the UML classes of the structural specification are connected by associations, many of which are of the one-to-many type. Associations whose name is preceded by / are derived — that is, their value is determined based on the value of other associations and attributes. Whether the objects 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 objects 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.

The narrative in this document often refers to various parts of the structural specification. These references are mainly intended to be informal, but they can often be interpreted as statements about the instances of the UML classes from the structural specification. When precision is required, such statements are captured using the functional-style syntax, which is defined in Section 3.7 and other relevant parts of this document. In order to avoid confusion, the term "UML class" is used to refer to elements of the structural specification of OWL 2, whereas the term "class" is used to refer to OWL 2 classes (see Section 5.1).

Objects o₁ and o₂ from the structural specification are structurally equivalent if the following conditions hold:

• If o₁ and o₂ are atomic values, such as strings or integers, they are structurally equivalent if they are equal according to the notion of equality of the respective UML 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 instances of UML classes from the structural specification, they are structurally equivalent if
  • both o₁ and o₂ are instances of the same UML class, and
  • each association of o₁ is structurally equivalent to the corresponding association of o₂ and vice versa.

The notion of structural equivalence is used throughout this specification to define various conditions on the structure of OWL 2 ontologies. Note that this is a syntactic, rather than a semantic notion — that is, it compares structures, rather than their meaning under a formal semantics.

Sets written in one of the exchange syntaxes (e.g., XML or RDF/XML) are not necessarily expected to be duplicate free. Duplicates SHOULD be eliminated when ontology documents written in such syntaxes are converted into instances of the UML classes of the structural specification.

2.2 BNF Notation

Grammars in this document are written using the BNF notation, summarized in Table 1.

The grammar presented in this document uses the following two "special" terminal symbols, which affect the process of transforming an input sequence of characters into a sequence of regular (i.e., not "special") terminal symbols:

• whitespace is a nonempty sequence of space (U+20), horizontal tab (U+9), line feed (U+A), or carriage return (U+D) characters, and
• a comment is a sequence of characters that starts with the # (U+23) character and does not contain the line feed (U+A) or carriage return (U+D) characters.

The following characters are called delimiters:

• = (U+3D)
• ( (U+28)
• ) (U+29)
• < (U+3C)
• > (U+3E)
• @ (U+40)
• ^ (U+5E)

Given an input sequence of characters, an OWL 2 implementation MUST exhibit the same observable behavior as if it applied the BNF grammar rules to the sequence of terminal symbols obtained from the input as follows.

1. For each terminal symbol (including whitespace and comment) mentioned in this document, a regular expression is created that can recognize the symbol's characters.
2. A pointer p is initialized to point to the beginning of input.
3. All regular expressions are matched to the characters in the input starting from p. Matches are greedy — that is, if several regular expressions match a portion of the input, a regular expression with the longest match wins. The regular expressions corresponding to terminal symbols in this document ensure that there are no ties (i.e., it is not possible for two regular expressions to match a portion of the input of the same length); thus, at most one regular expression can be matched.
4. If there is no match, the input SHOULD be rejected. Otherwise, if the matched regular expression does not correspond to the whitespace or comment terminal symbols, the corresponding terminal symbol is emitted to the output. (In other words, the matches of whitespace and comment are ignored.)
5. Pointer p is moved to the first character after the match.
6. If the terminal symbol matched in step 3 does not end with a delimiter character and p points to a character that is not a delimiter, then the regular expressions for whitespace and comment are matched to the characters in the input starting from p. If there is no match, the input SHOULD be rejected; otherwise, p is moved to the first character after the match (and thus the match is discarded).
7. If p does not point past the end of input, the process is repeated from step 3.

2.3 Integers, Characters, Strings, Language Tags, and Node IDs

Nonnegative integers are defined as usual.

Characters and strings are defined in the same way as in [RDF:PLAINLITERAL]. A character is an atomic unit of communication. The structure of characters is not further specified in this document, other than to note that each character has a Universal Character Set (UCS) code point [ISO/IEC 10646] (or, equivalently, a Unicode code point [UNICODE]). Each character MUST match the Char production from XML [XML]. Code points are written as U+ followed by the hexadecimal value of the code point. A string is a finite sequence of characters, and the length of a string is the number of characters in it. Two strings are identical if and only if they contain exactly the same characters in exactly the same sequence. Strings are written by enclosing them in double quotes (U+22) and using a subset of the N-triples escaping mechanism [RDF Test Cases] to encode strings containing quotes. Note that the definition below allows a string to span several lines of a document.

Language tags are used to identify the language in which a string has been written. They are defined in the same way as in [RDF:PLAINLITERAL], which follows [BCP 47]. Language tags are written by prepending them with the @ (U+40) character.

Node IDs are used to identify anonymous individuals (aka blank nodes in RDF [RDF Concepts]).

2.4 IRIs

Ontologies and their elements are identified using Internationalized Resource Identifiers (IRIs) [RFC3987]; thus, OWL 2 extends OWL 1, which uses Uniform Resource Identifiers (URIs). Each IRI MUST be absolute (i.e., not relative). In the structural specification, IRIs are represented by the IRI UML class. Two IRIs are structurally equivalent if and only if their string representations are identical.

IRIs can be written as full IRIs by enclosing them in a pair of < (U+3C) and > (U+3E) characters. These characters are not part of the IRI, but are used for quotation purposes to identify an IRI as a full IRI.

Alternatively, IRIs can be abbreviated as in SPARQL [SPARQL]. To this end, one can declare a prefix name pn: — that is, a possibly empty string followed by the : (U+3A) character — by associating it with a prefix IRI PI; then, an IRI I whose string representation consists of PI followed by the remaining characters rc can be abbreviated as pn:rc. By a slight abuse of terminology, a prefix name is often used to refer to the prefix IRI that is associated with the prefix name, and phrases such as "an IRI whose string representation starts with the prefix IRI associated with the prefix name pn:" are typically shortened to less verbose phrases such as "an IRI with prefix pn:".

If a concrete syntax uses this IRI abbreviation mechanism, it SHOULD provide a suitable mechanism for declaring prefix names. Furthermore, abbreviated IRIs are not represented in the structural specification of OWL 2, and OWL 2 implementations MUST exhibit the same observable behavior as if all abbreviated IRIs were expanded into full IRIs during parsing. Concrete syntaxes such as the RDF/XML Syntax [RDF Syntax] allow IRIs to be abbreviated in relation to the IRI of the document they are contained in. If used, such mechanisms are independent from the above described abbreviation mechanism. The abbreviated IRIs have the syntactic form of qualified names from the XML Namespaces specification [XML Namespaces]; therefore, it is common to refer to PI as a namespace and rc as a local name. This abbreviation mechanism, however, is independent from XML namespaces and can be understood as a simple macro mechanism that expands prefix names with the associated IRIs.

Table 2 declares the prefix names that are commonly used throughout this specification.

IRIs with prefixes rdf:, rdfs:, xsd:, and owl: constitute the reserved vocabulary of OWL 2. As described in the following sections, the IRIs from the reserved vocabulary that are listed in Table 3 have special treatment in OWL 2.

3 Ontologies

An OWL 2 ontology is an instance O of the Ontology UML class from the structural specification of OWL 2 shown in Figure 1 that satisfies certain conditions given below. The main component of an OWL 2 ontology is its set of axioms, the structure of which is described in more detail in Section 9. Because the association between an ontology and its axioms is a set, an ontology cannot contain two axioms that are structurally equivalent. Apart from axioms, ontologies can also contain ontology annotations (as described in more detail in Section 3.5), and they can also import other ontologies (as described in Section 3.4).

The following list summarizes all the conditions that O is required to satisfy to be an OWL 2 ontology.

• O MUST satisfy the restrictions on the presence of the ontology IRI and version IRI from Section 3.1.
• Each DataIntersectionOf and DataUnionOf in O MUST satisfy the restrictions from Section 7.1 and Section 7.2, respectively.
• Each DataSomeValuesFrom and DataAllValuesFrom class expression in O MUST satisfy the restrictions from Section 8.4.1 and Section 8.4.2, respectively.
• Each DataPropertyRange axiom in O MUST satisfy the restriction from Section 9.3.5.
• Each DatatypeDefinition axiom in O MUST satisfy the restrictions from Section 9.4.
• Each HasKey axiom in O MUST satisfy the restriction from Section 9.5.
• Each O' directly imported into O MUST satisfy all of these restrictions as well.

The following list summarizes all the conditions that an OWL 2 ontology O is required to satisfy to be an OWL 2 DL ontology.

• The ontology IRI and the version IRI (if present) of O MUST satisfy the restrictions on usage of the reserved vocabulary from Section 3.1.
• Each datatype and each literal in O MUST satisfy the restrictions from Section 5.2 and Section 5.7, respectively.
• Each entity in O MUST have an IRI satisfying the restrictions on the usage of the reserved vocabulary from Sections 5.1–5.6.
• O MUST satisfy the typing constraints from Section 5.8.1.
• Each DatatypeRestriction in O MUST satisfy the restriction on the usage of constraining facets from Section 7.5, respectively.
• O MUST satisfy the global restriction from Section 11.
• Each O' directly imported into O MUST satisfy all of these restrictions as well.

An instance O of the Ontology UML class MAY have consistent declarations as specified in Section 5.8.2; however, this is not strictly necessary to make O an OWL 2 ontology.

3.1 Ontology IRI and Version IRI

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

IRIs from the reserved vocabulary MUST NOT be used as an ontology IRI or a version IRI of an OWL 2 DL ontology.

The following list provides conventions for choosing ontology IRIs and version IRIs in OWL 2 ontologies. This specification provides no mechanism for enforcing these constraints across the entire Web; however, OWL 2 tools SHOULD use them to detect problems in ontologies they process.

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

The ontology IRI and the version IRI together identify a particular version from an ontology series — the set of all the versions of a particular ontology identified using a common ontology IRI. 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 the Ontology UML class from the structural specification. Ontology series are not represented explicitly in the structural specification of OWL 2: they exist only as a side effect of the naming conventions described in this and the following sections.

3.2 Ontology Documents

An OWL 2 ontology is an abstract notion defined in terms of the structural specification. Each ontology is associated with an ontology document, which physically contains the ontology stored in a particular way. The name "ontology document" reflects the expectation that a large number of ontologies will be stored in physical text documents written in one of the syntaxes of OWL 2. OWL 2 tools, however, are free to devise other types of ontology documents — that is, to introduce other ways of physically storing ontologies.

Ontology documents are not represented in the structural specification of OWL 2, and the specification of OWL 2 makes only the following two assumptions about their nature:

• Each ontology document can be accessed via an IRI by means of an appropriate protocol.
• Each ontology document can be converted in some well-defined way into an ontology (i.e., into an instance of the Ontology UML class from the structural specification).

The ontology document of an ontology O SHOULD be accessible via the IRIs determined by the following rules:

• If O does not contain an ontology IRI (and, consequently, it does not contain a version IRI either), then the ontology document of O MAY be accessible via any IRI.
• If O contains an ontology IRI OI but no version IRI, then the ontology document of O SHOULD be accessible via the IRI OI.
• If O contains an ontology IRI OI and a version IRI VI, then the ontology document of O SHOULD be accessible via the IRI VI; furthermore, if O is the current version of the ontology series with the IRI OI, then the ontology document of O SHOULD also be accessible via the IRI OI.

Thus, the document containing the current version of an ontology series with some IRI OI SHOULD be accessible via OI. To access a particular version of OI, one needs to know that version's version IRI VI; the ontology document of the version SHOULD then be accessible via VI.

OWL 2 tools will often need to implement functionality such as caching or off-line processing, where ontology documents may be stored at addresses different from the ones dictated by their ontology IRIs and version IRIs. OWL 2 tools MAY implement a redirection mechanism: when a tool is used to access an ontology document at IRI I, the tool MAY redirect I to a different IRI DI and access the ontology document via DI instead. The result of accessing the ontology document via DI MUST be the same as if the ontology were accessed via I. Furthermore, once the ontology document is converted into an ontology, the ontology SHOULD satisfy the three conditions from the beginning of this section in the same way as if it the ontology document were accessed via I. No particular redirection mechanism is specified — this is assumed to be implementation dependent.

3.3 Versioning of OWL 2 Ontologies

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

3.4 Imports

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

From a physical point of view, an ontology contains a set of IRIs, shown in Figure 1 as the directlyImportsDocuments association; these IRIs identify the ontology documents of the directly imported ontologies as specified in Section 3.2. The logical directly imports relation between ontologies, shown in Figure 1 as the directlyImports association, is obtained by accessing the directly imported ontology documents and converting them into OWL 2 ontologies. The logical imports relation between ontologies, shown in Figure 1 as the imports association, is the transitive closure of directly imports. In Figure 1, associations directlyImports and imports are shown as derived associations, since their values are derived from the value of the directlyImportsDocuments association. Ontology documents usually store the directlyImportsDocuments association. In contrast, the directlyImports and imports associations are typically not stored in ontology documents, but are determined during parsing as specified in Section 3.6.

The import closure of an ontology O is a set containing O and all the ontologies that O imports. The import closure of O 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 IRI or the version IRI 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 standardized apart — that is, the anonymous individuals from different ontologies in the import closure of O are treated as being different; see Section 5.6.2 for further details.

3.5 Ontology Annotations

An OWL 2 ontology contains a set of annotations. These can be used to associate information with an ontology — for example the ontology creator's name. As discussed in more detail in Section 10, each annotation consists of an annotation property and an annotation value, and the latter can be a literal, an IRI, or an anonymous individual.

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

• The owl:priorVersion annotation property specifies the IRI of a prior version of the containing ontology.
• The owl:backwardCompatibleWith annotation property specifies the IRI of a prior version of the containing ontology that is compatible with the current version of the containing ontology.
• The owl:incompatibleWith annotation property specifies the IRI of a prior version of the containing ontology that is incompatible with the current version of the containing ontology.

3.6 Canonical Parsing of OWL 2 Ontologies

Many OWL 2 tools need to support ontology parsing — the process of converting an ontology document written in a particular syntax into an OWL 2 ontology. Depending on the syntax used, the ontology parser may need to know which IRIs are used in the ontology as entities of which type. This typing information is extracted from declarations — axioms that associate IRIs with entity types. Please refer to Section 5.8 for more information about 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 placed in imported ontology documents 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.

An OWL 2 ontology corresponding to an ontology document D_GI accessible via a given IRI GI can be obtained using the following canonical parsing process. All steps of this process MUST be successfully completed.

It is important to understand that canonical parsing merely defines the result of the parsing process, and that an 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 IRI declarations before the axioms that use these IRIs; however, this is not required for conformance.

3.7 Functional-Style Syntax

A functional-style syntax ontology document is a sequence of Unicode characters [UNICODE] accessible via some IRI by means of the standard protocols such that its text matches the ontologyDocument production of the grammar defined in this specification document, and it can be converted into an ontology by means of the canonical parsing process described in Section 3.6 and other parts of this specification document. A functional-style syntax ontology document SHOULD use the UTF-8 encoding [RFC 3629].

Each part of the ontology document matching the prefixDeclaration production declares a prefix name and associates it with a prefix IRI. An ontology document MUST contain at most one such declaration per prefix name, and it MUST NOT declare a prefix name listed in Table 2. Prefix declarations are used during parsing to expand abbreviated IRIs in the ontology document — that is, parts of the ontology document matching the abbreviatedIRI production — into full IRIs. This is done as follows:

• The abbreviated IRI is split into a prefix name pn: — the part up to and including the : (U+3A) character — and the remaining part rp following the : (U+3A) character.
• If pn: is not one of the standard prefix names listed in Table 2, then the prefix declarations of the ontology document being parsed MUST contain a declaration for pn: associating it with a prefix IRI PI.
• The resulting full IRI is obtained by concatenating the string representation of PI with rp. The resulting IRI MUST be a valid IRI.

4 Datatype Maps

OWL 2 ontologies can refer to data values such as strings or integers. Each kind of such values is called a datatype. Datatypes can be used in OWL 2 ontologies as described in Section 5.2. Each datatype is identified by an IRI and is defined by the following components:

• The value space is the set of values of the datatype. Elements of the value space are called data values.
• The lexical space is a set of strings that can be used to refer to data values. Each member of the lexical space is called a lexical form, and it is mapped to a particular data value.
• The facet space is a set of pairs of the form ( F , v ) where F is an IRI called a constraining facet, and v is an arbitrary data value called the constraining value. Each such pair is mapped to a subset of the value space of the datatype.

A set of datatypes supported by a reasoner is called a datatype map. This is not a syntactic construct — that is, it is not used directly to construct OWL 2 ontologies in a way that, say, classes and datatypes are. Because of that, a datatype map is not represented in the structural specification of OWL 2.

The rest of this section defines a particular datatype map called the OWL 2 datatype map, which lists the datatypes that can be used in OWL 2 ontologies. Most datatypes are taken from the set of XML Schema Datatypes [XML Schema Datatypes], the RDF specification [RDF Concepts], or the specification for plain literals [RDF:PLAINLITERAL]. The normative definitions of these datatypes are provided by the respective specifications, and this document merely provides guidance on how to interpret these definitions properly in the context of OWL 2. For all these datatypes, this section lists the normative constraining facets that OWL 2 implementations MUST support. This section also contains the complete normative definitions of the datatypes owl:real and owl:rational, as these datatypes have not been taken from other specifications.

4.1 Real Numbers, Decimal Numbers, and Integers

The OWL 2 datatype map provides the following datatypes for the representation of real numbers, decimal numbers, and integers:

• owl:real
• owl:rational
• xsd:decimal
• xsd:integer
• xsd:nonNegativeInteger
• xsd:nonPositiveInteger
• xsd:positiveInteger
• xsd:negativeInteger
• xsd:long
• xsd:int
• xsd:short
• xsd:byte
• xsd:unsignedLong
• xsd:unsignedInt
• xsd:unsignedShort
• xsd:unsignedByte

For each datatype from the above list that is identified by an IRI with the xsd: prefix, the definitions of the value space, the lexical space, and the facet space are provided by XML Schema [XML Schema Datatypes]; furthermore, the normative constraining facets for the datatype are xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive, and xsd:maxExclusive. An OWL 2 implementation MAY support all lexical forms of these datatypes; however, it MUST support at least the lexical forms listed in Section 5.4 of XML Schema Datatypes [XML Schema Datatypes], which can be mapped to the primitive values commonly found in modern implementation platforms.

The datatypes owl:real and owl:rational are defined as follows.

Value Spaces.

• The value space of owl:real is the set of all real numbers.
• The value space of owl:rational is the set of all rational numbers. It is a subset of the value space of owl:real, and it contains the value space of xsd:decimal (and thus of all xsd: numeric datatypes listed above as well).

Lexical Spaces.

• The owl:real datatype does not directly provide any lexical forms.
• The owl:rational datatype supports lexical forms defined by the following grammar (whitespace within the grammar MUST be ignored and MUST NOT be included in the lexical forms of owl:rational, and single quotes are used to introduce terminal symbols):
  numerator '/' denominator
  Here, numerator is an integer with the syntax as specified for the xsd:integer datatype, and denominator is a positive, nonzero integer with the syntax as specified for the xsd:integer datatype, not containing the plus sign. Each such lexical form of owl:rational is mapped to the rational number obtained by dividing the value of numerator by the value of denominator. An OWL 2 implementation MAY support all such lexical forms; however, it MUST support at least the lexical forms where the numerator and the denominator are in the value space of xsd:long.

Facet Spaces. The facet spaces of owl:real and owl:rational are defined in Table 4.

4.2 Floating-Point Numbers

The OWL 2 datatype map supports the following datatypes for the representation of floating-point numbers:

• xsd:double
• xsd:float

As specified in XML Schema [XML Schema Datatypes], the value spaces of xsd:double, xsd:float, and xsd:decimal are pairwise disjoint. In accordance with this principle, the value space of owl:real is defined as being disjoint with the value spaces of xsd:double and xsd:float as well. The normative constraining facets for these datatypes are xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive, and xsd:maxExclusive.

4.3 Strings

The OWL 2 datatype map provides the rdf:PlainLiteral datatype for the representation of strings in a particular language. The definitions of the value space, the lexical space, the facet space, and the necessary mappings are given in [RDF:PLAINLITERAL]. The normative constraining facets for rdf:PlainLiteral are xsd:length, xsd:minLength, xsd:maxLength, xsd:pattern, and rdf:langRange; furthermore, only basic language ranges [BCP 47] are supported in the rdf:langRange constraining facet.

In addition, OWL 2 supports the following datatypes defined in XML Schema [XML Schema Datatypes]:

• xsd:string
• xsd:normalizedString
• xsd:token
• xsd:language
• xsd:Name
• xsd:NCName
• xsd:NMTOKEN

As explained in [RDF:PLAINLITERAL], the value spaces of all of these datatypes are contained in the value space of rdf:PlainLiteral. Furthermore, for each datatype from the above list, the normative constraining facets are xsd:length, xsd:minLength, xsd:maxLength, and xsd:pattern.

4.4 Boolean Values

The OWL 2 datatype map provides the xsd:boolean XML Schema datatype [XML Schema Datatypes] for the representation of Boolean values. No constraining facet is normative for this datatype.

4.5 Binary Data

The OWL 2 datatype map provides the following XML Schema datatypes [XML Schema Datatypes] for the representation of binary data:

• xsd:hexBinary
• xsd:base64Binary

As specified in XML Schema [XML Schema Datatypes], the value spaces of these two datatypes are disjoint. For each datatype from the above list, the normative constraining facets are xsd:minLength, xsd:maxLength, and xsd:length.

4.6 IRIs

The OWL 2 datatype map provides the xsd:anyURI XML Schema datatype [XML Schema Datatypes] for the representation of IRIs. As specified in XML Schema [XML Schema Datatypes], the value spaces of xsd:anyURI and xsd:string are disjoint. The normative constraining facets are xsd:minLength, xsd:maxLength, xsd:length, and xsd:pattern.

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

4.7 Time Instants

The OWL 2 datatype map provides the following XML Schema datatypes [XML Schema Datatypes] for the representation of time instants with and without time zone offsets:

• xsd:dateTime
• xsd:dateTimeStamp

For each datatype from the above list, the normative constraining facets are xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive, and xsd:maxExclusive. An OWL 2 implementation MAY support all lexical forms of these datatypes; however, it MUST support at least the lexical forms listed in Section 5.4 of XML Schema Datatypes [XML Schema Datatypes].

4.8 XML Literals

The OWL 2 datatype map provides the rdf:XMLLiteral datatype for the representation of XML content in OWL 2 ontologies. The datatype is defined in Section 5.1 of the RDF specification [RDF Concepts]. It has no normative constraining facets.

5 Entities, Literals, and Anonymous Individuals

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 uniquely identified by an IRI. Classes represent 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 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. Apart from named individuals, OWL 2 also provides for anonymous individuals — that is, individuals that are analogous to blank nodes in RDF [RDF Concepts] and that are accessible only from within the ontology they are used in. Finally, OWL 2 provides for literals, which consist of a string called a lexical form and a datatype specifying how to interpret this string.

5.1 Classes

Classes can be understood as sets of individuals.

The classes with the IRIs owl:Thing and owl:Nothing are available in OWL 2 as built-in classes with a predefined semantics:

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

IRIs from the reserved vocabulary other than owl:Thing and owl:Nothing MUST NOT be used to identify classes in an OWL 2 DL ontology.

5.2 Datatypes

Datatypes are entities that refer to sets of data values. Thus, datatypes are analogous to classes, the main difference being that the former contain data values such as strings and numbers, rather than individuals. Datatypes are a kind of data range, which allows them to be used in restrictions. As explained in Section 7, each data range is associated with an arity; for datatypes, the arity is always one. The built-in datatype rdfs:Literal denotes any set of data values that contains the union of the value spaces of all datatypes.

An IRI used to identify a datatype in an OWL 2 DL ontology MUST

• be rdfs:Literal, or
• identify a datatype in the OWL 2 datatype map (see Section 4), or
• not be in the reserved vocabulary of OWL 2 (see Section 2.4).

The conditions from the previous paragraph and the restrictions on datatypes in Section 11.2 require each datatype in an OWL 2 DL ontology to be rdfs:Literal, one of the datatypes from Section 4, or a datatype defined by means of a datatype definition (see Section 9.4).

5.3 Object Properties

Object properties connect pairs of individuals.

The object properties with the IRIs owl:topObjectProperty and owl:bottomObjectProperty are available in OWL 2 as built-in object properties with a predefined semantics:

• The object property with IRI owl:topObjectProperty connects all possible pairs of individuals.
• The object property with IRI owl:bottomObjectProperty does not connect any pair of individuals.

IRIs from the reserved vocabulary other than owl:topObjectProperty and owl:bottomObjectProperty MUST NOT be used to identify object properties in an OWL 2 DL ontology.

5.4 Data Properties

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

The data properties with the IRIs owl:topDataProperty and owl:bottomDataProperty are available in OWL 2 as built-in data properties with a predefined semantics:

• The data property with IRI owl:topDataProperty connects all possible individuals with all literals.
• The data property with IRI owl:bottomDataProperty does not connect any individual with a literal.

IRIs from the reserved vocabulary other than owl:topDataProperty and owl:bottomDataProperty MUST NOT be used to identify data properties in an OWL 2 DL ontology.

5.5 Annotation Properties

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

The annotation properties with the IRIs listed below are available in OWL 2 as built-in annotation properties with a predefined semantics:

• The rdfs:label annotation property can be used to provide an IRI with a human-readable label.
• The rdfs:comment annotation property can be used to provide an IRI with a human-readable comment.
• The rdfs:seeAlso annotation property can be used to provide an IRI with another IRI such that the latter provides additional information about the former.
• The rdfs:isDefinedBy annotation property can be used to provide an IRI with another IRI such that the latter provides information about the definition of the former; the way in which this information is provided 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 IRI is deprecated.
• The owl:versionInfo annotation property can be used to provide an IRI with a string that describes the IRI's version.
• The owl:priorVersion annotation property is described in more detail in Section 3.5.
• The owl:backwardCompatibleWith annotation property is described in more detail in Section 3.5.
• The owl:incompatibleWith annotation property is described in more detail in Section 3.5.

IRIs from the reserved vocabulary other than the ones listed above MUST NOT be used to identify annotation properties in an OWL 2 DL ontology.

5.6 Individuals

Individuals in the OWL 2 syntax represent actual objects from the domain. There are two types of individuals in the syntax of OWL 2. Named individuals are given an explicit name that can be used in any ontology to refer to the same object. Anonymous individuals do not have a global name and are thus local to the ontology they are contained in.

5.6.1 Named Individuals

Named individuals are identified using an IRI. Since they are given an IRI, named individuals are entities.

IRIs from the reserved vocabulary MUST NOT be used to identify named individuals in an OWL 2 DL ontology.

5.6.2 Anonymous Individuals

If an individual is not expected to be used outside a particular ontology, one can use an anonymous individual, which is identified by a local node ID rather than a global IRI. Anonymous individuals are analogous to blank nodes in RDF [RDF Concepts].

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 not treated as identical in the semantics of OWL 2 (because anonymous individuals are local to an ontology they are used in). The latter is achieved by standardizing anonymous individuals apart when constructing the axiom closure of an ontology 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 axiom closure of O with a fresh anonymous individual (i.e., an anonymous individual whose node ID is unique in the import closure of O).

5.7 Literals

Literals represent data values such as particular strings or integers. They are analogous to typed RDF literals [RDF Concepts] and can also be understood as individuals denoting data values. Each literal consists of a lexical form, which is a string, and a datatype; the datatypes supported in OWL 2 are described in more detail in Section 4. A literal consisting of a lexical form "abc" and a datatype identified by the IRI datatypeIRI is written as "abc"^^datatypeIRI. Furthermore, literals whose datatype is rdf:PlainLiteral can be abbreviated in functional-style syntax ontology documents as plain RDF literals [RDF Concepts]. These abbreviations are purely syntactic shortcuts and are thus not reflected in the structural specification of OWL 2. The observable behavior of OWL 2 implementation MUST be as if these shortcuts were expanded during parsing.

• Literals of the form "abc@"^^rdf:PlainLiteral SHOULD be abbreviated in functional-style syntax ontology documents to "abc" whenever possible.
• Literals of the form "abc@langTag"^^rdf:PlainLiteral where "langTag" is not empty SHOULD be abbreviated in functional-style syntax documents to "abc"@langTag whenever possible.

The lexical form of each literal occurring in an OWL 2 DL ontology MUST belong to the lexical space of the literal's datatype.

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

5.8 Entity Declarations and Typing

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

• A declaration says that I exists — that is, it says that I is part of the vocabulary of O.
• A declaration associates with I an entity type — that is, it says whether I is used in O as 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 in the ontology. These axioms are nonlogical in the sense that they do not affect the consequences of an OWL 2 ontology. The structure of entity declarations is shown in Figure 3.

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

5.8.1 Typing Constraints of OWL 2 DL

Let Ax be a set of axioms. An IRI I is declared to be of type T in Ax if a declaration axiom of type T for I is contained in Ax or in the set of built-in declarations listed in Table 5. The set Ax satisfies the typing constraints of OWL 2 DL if all of the following conditions are satisfied:

• Property typing constraints:
  • If an object property with an IRI I occurs in some axiom in Ax, then I is declared in Ax as an object property.
  • If a data property with an IRI I occurs in some axiom in Ax, then I is declared in Ax as a data property.
  • If an annotation property with an IRI I occurs in some axiom in Ax, then I is declared in Ax as an annotation property.
  • No IRI I is declared in Ax as being of more than one type of property; that is, no I is declared in Ax to be both object and data, object and annotation, or data and annotation property.
• Class/datatype typing constraints:
  • If a class with an IRI I occurs in some axiom in Ax, then I is declared in Ax as a class.
  • If a datatype with an IRI I occurs in some axiom in Ax, then I is declared in Ax as a datatype.
  • No IRI I is declared in ax to be both a class and a datatype.

The axiom closure Ax of each OWL 2 DL ontology O MUST satisfy the typing constraints of OWL 2 DL.

The typing constraints thus ensure that the sets of IRIs used as object, data, and annotation properties in O are disjoint and that, similarly, the sets of IRIs used as classes and datatypes in O are disjoint as well. These constraints are used for disambiguating the types of IRIs 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 the types of entities are clear.

5.8.2 Declaration Consistency

Although declarations are not always required, they can be used to catch obvious errors in ontologies.

An ontology O is said to have consistent declarations if each IRI I occurring in the axiom closure of O in position of an entity with a type T is declared in O as having type T. OWL 2 ontologies are not required to have consistent declarations: an ontology MAY be used even if its declarations are not consistent.

5.9 Metamodeling

An IRI I can be used in an OWL 2 ontology to refer to more than one type of entity. Such usage of I is often called metamodeling, because it can be used to state facts about classes and properties themselves. In such cases, the entities that share the same IRI I should be understood as different "views" of the same underlying notion identified by the IRI I.

Both metamodeling and annotations provide means to associate additional information with classes and properties. The following rule-of-the-thumb can be used to determine when to use which construct:

• Metamodeling should be used when the information attached to entities should be considered a part of the domain.
• Annotations should be used when the information attached to entities should not be considered a part of the domain and when it should not contribute to the logical consequences of an 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, which represent relationships between pairs of individuals. 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 ObjectInverseOf( 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 data property expressions, which represent relationships between an individual and a literal. The structure of data property expressions is 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 xsd:string or xsd:integer, and literals such as "1"^^xsd:integer, can be used to express data ranges — sets of tuples of literals, where tuples consisting of only one literal are identified with the literal itself. 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" allowing implementations to introduce extensions such as 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 DataIntersectionOf, DataUnionOf, and DataComplementOf data ranges provide for the standard set-theoretic operations on data ranges; in logical languages these are usually called conjunction, disjunction, and negation, respectively. The DataOneOf data range consists of exactly the specified set of literals. Finally, the DatatypeRestriction data range restricts the value space of a datatype by a constraining facet.

7.1 Intersection of Data Ranges

An intersection data range DataIntersectionOf( DR₁ ... DR_n ) contains all tuples of literals that are contained in each data range DR_i for 1 ≤ i ≤ n. All data ranges DR_i MUST be of the same arity, and the resulting data range is of that arity as well.

7.2 Union of Data Ranges

A union data range DataUnionOf( DR₁ ... DR_n ) contains all tuples of literals that are contained in the at least one data range DR_i for 1 ≤ i ≤ n. All data ranges DR_i MUST be of the same arity, and the resulting data range is of that arity as well.

7.3 Complement of Data Ranges

A complement data range DataComplementOf( DR ) contains all tuples of literals that are not contained in the data range DR. The resulting data range has the arity equal to the arity of DR.

7.4 Enumeration of Literals

An enumeration of literals DataOneOf( lt₁ ... lt_n ) contains exactly the explicitly specified literals lt_i with 1 ≤ i ≤ n. The resulting data range has arity one.

7.5 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 resulting data range is unary and is obtained by restricting the value space of DT according to the semantics of all ( F_i , v_i ) (multiple pairs are interpreted conjunctively), where v_i are the data values of the literals lt_i.

In an OWL 2 DL ontology, each pair ( F_i , v_i ) MUST be contained in the facet space of DT (see Section 4).

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 on the individuals' properties; individuals satisfying 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; enumeration of individuals; 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 Enumeration of Individuals

OWL 2 provides for enumeration of individuals and all standard Boolean connectives, as shown in Figure 7. The ObjectIntersectionOf, ObjectUnionOf, and ObjectComplementOf class expressions provide for the standard set-theoretic operations on class expressions; in logical languages these are usually called conjunction, disjunction, and negation, respectively. The ObjectOneOf class expression contains exactly the specified individuals.

8.1.1 Intersection of Class Expressions

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

8.1.2 Union of Class Expressions

A union class expression ObjectUnionOf( 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 of Class Expressions

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

8.1.4 Enumeration of Individuals

An enumeration of individuals ObjectOneOf( 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 it contains those individuals that are connected through an object property expression to at least one instance of a given class expression. The ObjectAllValuesFrom class expression allows for universal quantification over an object property expression, and it 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 ObjectHasSelf class expression contains those individuals that are connected by an object property expression to themselves.

8.2.1 Existential Quantification

An existential class expression ObjectSomeValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and it 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 ObjectMinCardinality( 1 OPE CE ).

8.2.2 Universal Quantification

A universal class expression ObjectAllValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and it 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 ObjectMaxCardinality( 0 OPE ObjectComplementOf( CE ) ).

8.2.3 Individual Value Restriction

A has-value class expression ObjectHasValue( OPE a ) consists of an object property expression OPE and an individual a, and it contains all those individuals that are connected by OPE to a. Each such class expression can be seen as a syntactic shortcut for the class expression ObjectSomeValuesFrom( OPE ObjectOneOf( a ) ).

8.2.4 Self-Restriction

A self-restriction ObjectHasSelf( OPE ) consists of an object property expression OPE, and it contains all those individuals that are connected by OPE 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: in the former case, the cardinality restriction only applies to individuals that are connected by the object property expression and are instances of the qualifying class expression; in the latter case the restriction applies to all individuals that are connected by the object property expression (this is equivalent to the qualified case 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 ObjectMinCardinality( 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 ObjectMaxCardinality( 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 ObjectExactCardinality( 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 at least one literal in the given data range. The DataAllValuesFrom class expression allows for a restricted universal quantification over a list of data property expressions, 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 DataSomeValuesFrom( DPE₁ ... DPE_n DR ) consists of n data property expressions DPE_i, 1 ≤ i ≤ n, and a data range DR whose arity MUST be n. Such a class expression 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 DataSomeValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expression DataMinCardinality( 1 DPE DR ).

8.4.2 Universal Quantification

A universal class expression DataAllValuesFrom( DPE₁ ... DPE_n DR ) consists of n data property expressions DPE_i, 1 ≤ i ≤ n, and a data range DR whose arity MUST be n. Such a class expression 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 DataAllValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expression DataMaxCardinality( 0 DPE DataComplementOf( DR ) ).

8.4.3 Literal Value Restriction

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

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: in the former case, the cardinality restriction only applies to literals that are connected by the data property expression and are in the qualifying data range; in the latter case it applies to all literals that are connected by the data property expression (this is equivalent to the qualified case 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 DataMinCardinality( n DPE DR ) consists of a nonnegative integer n, a data property expression DPE, and a unary data range DR, and it 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.

Note that some datatypes from the OWL 2 datatype map distinguish between equal and identical data values, and that the semantics of cardinality restrictions in OWL 2 is defined with respect to the latter. For an example demonstrating the effects such such a definition, please refer to Section 9.3.6.

8.5.2 Maximum Cardinality

A maximum cardinality expression DataMaxCardinality( n DPE DR ) consists of a nonnegative integer n, a data property expression DPE, and a unary data range DR, and it 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.

Note that some datatypes from the OWL 2 datatype map distinguish between equal and identical data values, and that the semantics of cardinality restrictions in OWL 2 is defined with respect to the latter. For an example demonstrating the effects such such a definition, please refer to Section 9.3.6.

8.5.3 Exact Cardinality

An exact cardinality expression DataExactCardinality( n DPE DR ) consists of a nonnegative integer n, a data property expression DPE, and a unary data range DR, and it 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.

Note that some datatypes from the OWL 2 datatype map distinguish between equal and identical data values, and that the semantics of cardinality restrictions in OWL 2 is defined with respect to the latter. For an example demonstrating the effects such such a definition, please refer to Section 9.3.6.

9 Axioms

The main component of an OWL 2 ontology is a set of axioms — statements that say what is true in the domain. OWL 2 provides an extensive set of axioms, all of which extend the Axiom class in the structural specification. As shown in Figure 12, axioms in OWL 2 can be declarations, axioms about classes, axioms about object or data properties, datatype definitions, keys, assertions (sometimes also called facts), and axioms about annotations.

As shown in Figure 1, OWL 2 axioms can contain axiom annotations, the structure of which is defined in Section 10. Axiom annotations have no effect on the semantics of axioms — that is, they do not affect the logical consequences of OWL 2 ontologies. In contrast, axiom annotations do affect structural equivalence: axioms will not be structurally equivalent if their axiom annotations are not structurally equivalent.

9.1 Class Expression Axioms

OWL 2 provides axioms that allow relationships to be established between 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 pairwise disjoint — that is, that 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. Other kinds of class expression axiom can be seen as syntactic shortcuts for one or more subclass axioms.

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 called 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 pairwise disjoint; that is, no individual can be at the same time an instance of both CE_i and CE_j for i ≠ j. An axiom DisjointClasses( CE₁ CE₂ ) is equivalent to the following axiom:

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 pairwise disjoint. 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 can be seen as a syntactic shortcut for the following two axioms:

9.2 Object Property Axioms

OWL 2 provides axioms that can be used to characterize and establish relationships between 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 pairwise disjoint — that is, that they do not share pairs of connected individuals. The InverseObjectProperties axiom can be used to state that two object property expressions are the inverse of each other. 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 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 SubObjectPropertyOf( 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 SubObjectPropertyOf( ObjectPropertyChain( 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 EquivalentObjectProperties( OPE₁ ... OPE_n ) states that all of the object property expressions OPE_i, 1 ≤ i ≤ n, are semantically equivalent to 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 EquivalentObjectProperties( OPE₁ OPE₂ ) is equivalent to the following two axioms:

9.2.3 Disjoint Object Properties

A disjoint object properties axiom DisjointObjectProperties( OPE₁ ... OPE_n ) states that all of the object property expressions OPE_i, 1 ≤ i ≤ n, are pairwise disjoint; that is, no individual x can be connected to an individual y by both OPE_i and OPE_j for i ≠ j.

9.2.4 Inverse Object Properties

An inverse object properties axiom InverseObjectProperties( 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₁ to an individual y, then y is also connected by OPE₂ to x, and vice versa. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.5 Object Property Domain

An object property domain axiom ObjectPropertyDomain( 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. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.6 Object Property Range

An object property range axiom ObjectPropertyRange( 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. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.7 Functional Object Properties

An object property functionality axiom FunctionalObjectProperty( 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. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.8 Inverse-Functional Object Properties

An object property inverse functionality axiom InverseFunctionalObjectProperty( 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. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.9 Reflexive Object Properties

An object property reflexivity axiom ReflexiveObjectProperty( OPE ) states that the object property expression OPE is reflexive — that is, each individual is connected by OPE to itself. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.10 Irreflexive Object Properties

An object property irreflexivity axiom IrreflexiveObjectProperty( OPE ) states that the object property expression OPE is irreflexive — that is, no individual is connected by OPE to itself. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.11 Symmetric Object Properties

An object property symmetry axiom SymmetricObjectProperty( 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. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.12 Asymmetric Object Properties

An object property asymmetry axiom AsymmetricObjectProperty( 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 TransitiveObjectProperty( 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. Each such axiom can be seen as a syntactic shortcut for the following 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 unary 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.

9.3.1 Data Subproperties

A data subproperty axiom SubDataPropertyOf( 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 DPE₁ to a literal y, then x is connected by DPE₂ to y as well.

9.3.2 Equivalent Data Properties

An equivalent data properties axiom EquivalentDataProperties( 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 EquivalentDataProperties( DPE₁ DPE₂ ) can be seen as a syntactic shortcut for the following axiom:

9.3.3 Disjoint Data Properties

A disjoint data properties axiom DisjointDataProperties( DPE₁ ... DPE_n ) states that all of the data property expressions DPE_i, 1 ≤ i ≤ n, are pairwise disjoint; that is, no individual x can be connected to a literal y by both DPE_i and DPE_j for i ≠ j.

9.3.4 Data Property Domain

A data property domain axiom DataPropertyDomain( 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 can be seen as a syntactic shortcut for the following axiom:

9.3.5 Data Property Range

A data property range axiom DataPropertyRange( 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. The arity of DR MUST be one. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.3.6 Functional Data Properties

A data property functionality axiom FunctionalDataProperty( 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 can be seen as a syntactic shortcut for the following axiom: