Movatterモバイル変換

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 theerrata for this document, which may include some normative corrections.

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

Copyright © 2012W3C^® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark anddocument 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 theW3C technical reports index at http://www.w3.org/TR/.

Summary of Changes

Please Send Comments

Please send any comments topublic-owl-comments@w3.org (public archive). Although work on this document by theOWL Working Group is complete, comments may be addressed in theerrata or in future revisions. Open discussion among developers is welcome atpublic-owl-dev@w3.org (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 the5 February 2004 W3C Patent Policy. W3C maintains apublic 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 thestructural 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 thefunctional-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 primitiveterms of an ontology and constitute the basic elements of an ontology. For example, a classa:Person can be used to represent the set of all people. Similarly, the object propertya:parentOf can be used to represent the parent-child relationship. Finally, the individuala:Peter can be used to represent a particular person called"Peter".
• Expressions represent complex notions in the domain being described. For example, aclass 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 asubclass axiom, one can state that the classa:Student is a subclass of the classa:Person.

These three syntactic categories are used to express thelogical 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 individuala:Peter is an instance of the classa:Student, anda:Student is a subclass ofa:Person, then from the OWL 2 semantics one can derive thata:Peter is also an instance ofa:Person.

In addition, entities, axioms, and ontologies can beannotated 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 ontologyO can import another OWL 2 ontologyO' and thus gain access to all entities, expressions, and axioms inO'.

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 keywordsMUST,MUST NOT,SHOULD,SHOULD NOT, andMAY 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 toolMAY base its APIs and/or internal storage model on the structural specification; however, itMAY 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/ arederived — 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 inSection 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 (seeSection 5.1).

Objectso₁ ando₂ from the structural specification arestructurally equivalent if the following conditions hold:

• Ifo₁ ando₂ 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.
• Ifo₁ ando₂ are unordered associations without repetitions, they are structurally equivalent if each element ofo₁ is structurally equivalent to some element ofo₂ and vice versa.
• Ifo₁ ando₂ are ordered associations with repetitions, they are structurally equivalent if they contain the same number of elements and each element ofo₁ is structurally equivalent to the element ofo₂ with the same index.
• Ifo₁ ando₂ are instances of UML classes from the structural specification, they are structurally equivalent if
  • botho₁ ando₂ are instances of the same UML class, and
  • each association ofo₁ is structurally equivalent to the corresponding association ofo₂ 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. DuplicatesSHOULD 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
• acomment 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 calleddelimiters:

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

Given an input sequence of characters, an OWL 2 implementationMUST 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 (includingwhitespace andcomment) mentioned in this document, a regular expression is created that can recognize the symbol's characters.
2. A pointerp is initialized to point to the beginning of input.
3. All regular expressions are matched to the characters in the input starting fromp. 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 inputSHOULD be rejected. Otherwise, if the matched regular expression does not correspond to thewhitespace orcomment terminal symbols, the corresponding terminal symbol is emitted to the output. (In other words, the matches ofwhitespace andcomment are ignored.)
5. Pointerp 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 andp points to a character that is not a delimiter, then the regular expressions forwhitespace andcomment are matched to the characters in the input starting fromp. If there is no match, the inputSHOULD be rejected; otherwise,p is moved to the first character after the match (and thus the match is discarded).
7. Ifp 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]. Acharacter 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 characterMUST match theChar production from XML [XML]. Code points are written as U+ followed by the hexadecimal value of the code point. Astring is a finite sequence of characters, and thelength 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 (akablank 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 IRIMUST be absolute (i.e., not relative). In the structural specification, IRIs are represented by theIRI 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 candeclare aprefix namepn: — that is, a possibly empty string followed by the: (U+3A) character — by associating it with aprefix IRIPI; then, an IRII whose string representation consists ofPI followed by the remaining charactersrc can be abbreviated aspn: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 namepn:" are typically shortened to less verbose phrases such as "an IRI with prefixpn:".

If a concrete syntax uses this IRI abbreviation mechanism, itSHOULD provide a suitable mechanism for declaring prefix names. Furthermore, abbreviated IRIs are not represented in the structural specification of OWL 2, and OWL 2 implementationsMUST 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 toPI as anamespace andrc as alocal 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 prefixesrdf:,rdfs:,xsd:, andowl: constitute thereserved 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 2ontology is an instanceO of theOntology 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 inSection 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 inSection 3.5), and they can also import other ontologies (as described inSection 3.4).

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

• OMUST satisfy the restrictions on the presence of the ontology IRI and version IRI fromSection 3.1.
• EachDataIntersectionOf andDataUnionOf inOMUST satisfy the restrictions fromSection 7.1 andSection 7.2, respectively.
• EachDataSomeValuesFrom andDataAllValuesFrom class expression inOMUST satisfy the restrictions fromSection 8.4.1 andSection 8.4.2, respectively.
• EachDataPropertyRange axiom inOMUST satisfy the restriction fromSection 9.3.5.
• EachDatatypeDefinition axiom inOMUST satisfy the restrictions fromSection 9.4.
• EachHasKey axiom inOMUST satisfy the restriction fromSection 9.5.
• EachO' directly imported intoOMUST satisfy all of these restrictions as well.

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

• The ontology IRI and the version IRI (if present) ofOMUST satisfy the restrictions on usage of the reserved vocabulary fromSection 3.1.
• Each datatype and each literal inOMUST satisfy the restrictions fromSection 5.2 andSection 5.7, respectively.
• Each entity inOMUST have an IRI satisfying the restrictions on the usage of the reserved vocabulary from Sections5.1–5.6.
• OMUST satisfy the typing constraints fromSection 5.8.1.
• EachDatatypeRestriction inOMUST satisfy the restriction on the usage of constraining facets fromSection 7.5, respectively.
• OMUST satisfy the global restriction fromSection 11.
• EachO' directly imported intoOMUST satisfy all of these restrictions as well.

An instanceO of theOntology UML classMAY have consistent declarations as specified inSection 5.8.2; however, this is not strictly necessary to makeO an OWL 2 ontology.

3.1 Ontology IRI and Version IRI

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

IRIs from the reserved vocabularyMUST 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 toolsSHOULD 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 IRISHOULD 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 IRISHOULD NOT exist.
• All other combinations of the ontology IRI and version IRI are not required to be unique. Thus, two different ontologiesMAY have no ontology IRI and no version IRI; similarly, an ontology containing only an ontology IRIMAY 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 anontology 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 thecurrent one. Structurally, a version of a particular ontology is an instance of theOntology 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 anontology 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 theOntology UML class from the structural specification).

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

• IfO does not contain an ontology IRI (and, consequently, it does not contain a version IRI either), then the ontology document ofOMAY be accessible via any IRI.
• IfO contains an ontology IRIOI but no version IRI, then the ontology document ofOSHOULD be accessible via the IRIOI.
• IfO contains an ontology IRIOI and a version IRIVI, then the ontology document ofOSHOULD be accessible via the IRIVI; furthermore, ifO is the current version of the ontology series with the IRIOI, then the ontology document ofOSHOULD also be accessible via the IRIOI.

Thus, the document containing the current version of an ontology series with some IRIOISHOULD be accessible viaOI. To access a particular version ofOI, one needs to know that version's version IRIVI; the ontology document of the versionSHOULD then be accessible viaVI.

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 toolsMAY implement aredirection mechanism: when a tool is used to access an ontology document at IRII, the toolMAY redirectI to a different IRIDI and access the ontology document viaDI instead. The result of accessing the ontology document viaDIMUST be the same as if the ontology were accessed viaI. Furthermore, once the ontology document is converted into an ontology, the ontologySHOULD satisfy the three conditions from the beginning of this section in the same way as if it the ontology document were accessed viaI. No particular redirection mechanism is specified — this is assumed to be implementation dependent.

3.3 Versioning of OWL 2 Ontologies

The conventions fromSection 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 seriesSHOULD be accessible via the ontology IRI and, if present, via its version IRI as well; the ontology documents of the previous versionsSHOULD be accessible solely via their respective version IRIs. When a new versionO in the ontology series is created, the ontology document ofOSHOULD replace the one accessible via the ontology IRI (and itSHOULD 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 thedirectlyImportsDocuments association; these IRIs identify the ontology documents of the directly imported ontologies as specified inSection 3.2. The logicaldirectly imports relation between ontologies, shown in Figure 1 as thedirectlyImports association, is obtained by accessing the directly imported ontology documents and converting them into OWL 2 ontologies. The logicalimports relation between ontologies, shown in Figure 1 as theimports association, is the transitive closure of directly imports. In Figure 1, associationsdirectlyImports andimports are shown as derived associations, since their values are derived from the value of thedirectlyImportsDocuments association. Ontology documents usually store thedirectlyImportsDocuments association. In contrast, thedirectlyImports andimports associations are typically not stored in ontology documents, but are determined during parsing as specified inSection 3.6.

Theimport closure of an ontologyO is a set containingO and all the ontologies thatO imports. The import closure ofOSHOULD NOT contain ontologiesO₁ andO₂ such that

• O₁ andO₂ are different ontology versions from the same ontology series, or
• O₁ contains an ontology annotationowl:incompatibleWith with the value equal to either the ontology IRI or the version IRI ofO₂.

Theaxiom closure of an ontologyO is the smallest set that contains all the axioms from each ontologyO' in the import closure ofO with all anonymous individualsstandardized apart — that is, the anonymous individuals from different ontologies in the import closure ofO are treated as being different; seeSection 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 inSection 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.

• Theowl:priorVersion annotation property specifies the IRI of a prior version of the containing ontology.
• Theowl: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.
• Theowl: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 supportontology 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 toSection 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 ofcanonical parsing. An OWL 2 parserMAY 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 documentD_GI accessible via a given IRIGI can be obtained using the followingcanonical parsing process. All steps of this processMUST 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 2MAY 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

Afunctional-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 theontologyDocument 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 inSection 3.6 and other parts of this specification document. A functional-style syntax ontology documentSHOULD use the UTF-8 encoding [RFC 3629].

Each part of the ontology document matching theprefixDeclaration production declares a prefix name and associates it with a prefix IRI. An ontology documentMUST contain at most one such declaration per prefix name, and itMUST 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 theabbreviatedIRI production — into full IRIs. This is done as follows:

• The abbreviated IRI is split into a prefix namepn: — the part up to and including the: (U+3A) character — and the remaining partrp following the: (U+3A) character.
• Ifpn: is not one of the standard prefix names listed in Table 2, then the prefix declarations of the ontology document being parsedMUST contain a declaration forpn: associating it with a prefix IRIPI.
• The resulting full IRI is obtained by concatenating the string representation ofPI withrp. The resulting IRIMUST 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 adatatype. Datatypes can be used in OWL 2 ontologies as described inSection 5.2. Each datatype is identified by an IRI and is defined by the following components:

• Thevalue space is the set of values of the datatype. Elements of the value space are calleddata values.
• Thelexical space is a set of strings that can be used to refer to data values. Each member of the lexical space is called alexical form, and it is mapped to a particular data value.
• Thefacet space is a set of pairs of the form (F ,v ) whereF is an IRI called aconstraining facet, andv is an arbitrary data value called theconstraining 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 adatatype 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 theOWL 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 thenormative constraining facets that OWL 2 implementationsMUST support. This section also contains the complete normative definitions of the datatypesowl:real andowl: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 thexsd: 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 arexsd:minInclusive,xsd:maxInclusive,xsd:minExclusive, andxsd:maxExclusive. An OWL 2 implementationMAY support all lexical forms of these datatypes; however, itMUST 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 datatypesowl:real andowl:rational are defined as follows.

Value Spaces.

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

Lexical Spaces.

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

Facet Spaces. The facet spaces ofowl:real andowl: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 ofxsd:double,xsd:float, andxsd:decimal are pairwise disjoint. In accordance with this principle, the value space ofowl:real is defined as being disjoint with the value spaces ofxsd:double andxsd:float as well. The normative constraining facets for these datatypes arexsd:minInclusive,xsd:maxInclusive,xsd:minExclusive, andxsd:maxExclusive.

4.3 Strings

The OWL 2 datatype map provides therdf: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 forrdf:PlainLiteral arexsd:length,xsd:minLength,xsd:maxLength,xsd:pattern, andrdf:langRange; furthermore, onlybasic language ranges [BCP 47] are supported in therdf: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 ofrdf:PlainLiteral. Furthermore, for each datatype from the above list, the normative constraining facets arexsd:length,xsd:minLength,xsd:maxLength, andxsd:pattern.

4.4 Boolean Values

The OWL 2 datatype map provides thexsd: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 arexsd:minLength,xsd:maxLength, andxsd:length.

4.6 IRIs

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

The lexical forms ofxsd: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] usesxml:base for that purpose), such rules do not apply toxsd:anyURI lexical forms that represent relative IRIs; that is, the lexical forms representing relative IRIsMUST 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 arexsd:minInclusive,xsd:maxInclusive,xsd:minExclusive, andxsd:maxExclusive. An OWL 2 implementationMAY support all lexical forms of these datatypes; however, itMUST 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 therdf: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 thesignature 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 alexical 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 IRIsowl:Thing andowl:Nothing are available in OWL 2 as built-in classes with a predefined semantics:

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

IRIs from the reserved vocabulary other thanowl:Thing andowl:NothingMUST 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 inSection 7, each data range is associated with an arity; for datatypes, the arity is always one. The built-in datatyperdfs: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 ontologyMUST

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

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

5.3 Object Properties

Object properties connect pairs of individuals.

The object properties with the IRIsowl:topObjectProperty andowl:bottomObjectProperty are available in OWL 2 as built-in object properties with a predefined semantics:

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

IRIs from the reserved vocabulary other thanowl:topObjectProperty andowl:bottomObjectPropertyMUST 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 calledattributes.

The data properties with the IRIsowl:topDataProperty andowl:bottomDataProperty are available in OWL 2 as built-in data properties with a predefined semantics:

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

IRIs from the reserved vocabulary other thanowl:topDataProperty andowl:bottomDataPropertyMUST 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 inSection 10.

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

• Therdfs:label annotation property can be used to provide an IRI with a human-readable label.
• Therdfs:comment annotation property can be used to provide an IRI with a human-readable comment.
• Therdfs:seeAlso annotation property can be used to provide an IRI with another IRI such that the latter provides additional information about the former.
• Therdfs: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 theowl:deprecated annotation property and the value equal to"true"^^xsd:boolean can be used to specify that an IRI is deprecated.
• Theowl:versionInfo annotation property can be used to provide an IRI with a string that describes the IRI's version.
• Theowl:priorVersion annotation property is described in more detail inSection 3.5.
• Theowl:backwardCompatibleWith annotation property is described in more detail inSection 3.5.
• Theowl:incompatibleWith annotation property is described in more detail inSection 3.5.

IRIs from the reserved vocabulary other than the ones listed aboveMUST 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 vocabularyMUST 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 ananonymous 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 bystandardizing anonymous individuals apart when constructing the axiom closure of an ontologyO: if anonymous individuals with the same node ID occur in two different ontologies in the import closure ofO, then one of these individualsMUST be replaced in the axiom closure ofO with a fresh anonymous individual (i.e., an anonymous individual whose node ID is unique in the import closure ofO).

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 inSection 4. A literal consisting of a lexical form"abc" and a datatype identified by the IRIdatatypeIRI is written as"abc"^^datatypeIRI. Furthermore, literals whose datatype isrdf: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 implementationMUST be as if these shortcuts were expanded during parsing.

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

The lexical form of each literal occurring in an OWL 2 DL ontologyMUST 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 IRII used in an OWL 2 ontologyO can be, and sometimes even needs to be, declared inO; roughly speaking, this means that the axiom closure ofO must contain an appropriate declaration forI. A declaration forI inO serves two purposes:

• A declaration says thatI exists — that is, it says thatI is part of the vocabulary ofO.
• A declaration associates withI an entity type — that is, it says whetherI is used inO 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

LetAx be a set of axioms. An IRII isdeclared to be of typeT inAx if a declaration axiom of typeT forI is contained inAx or in the set of built-in declarations listed in Table 5. The setAx satisfies thetyping constraints of OWL 2 DL if all of the following conditions are satisfied:

• Property typing constraints:
  • If an object property with an IRII occurs in some axiom inAx, thenI is declared inAx as an object property.
  • If a data property with an IRII occurs in some axiom inAx, thenI is declared inAx as a data property.
  • If an annotation property with an IRII occurs in some axiom inAx, thenI is declared inAx as an annotation property.
  • No IRII is declared inAx as being of more than one type of property; that is, noI is declared inAx to be both object and data, object and annotation, or data and annotation property.
• Class/datatype typing constraints:
  • If a class with an IRII occurs in some axiom inAx, thenI is declared inAx as a class.
  • If a datatype with an IRII occurs in some axiom inAx, thenI is declared inAx as a datatype.
  • No IRII is declared inax to be both a class and a datatype.

The axiom closureAx of each OWL 2 DL ontologyOMUST 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 inO are disjoint and that, similarly, the sets of IRIs used as classes and datatypes inO 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 ontologyO is said to haveconsistent declarations if each IRII occurring in the axiom closure ofO in position of an entity with a typeT is declared inO as having typeT. OWL 2 ontologies are not required to have consistent declarations: an ontologyMAY be used even if its declarations are not consistent.

5.9 Metamodeling

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

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 byObjectPropertyExpression, 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 expressionObjectInverseOf( P ) connects an individualI₁ withI₂ if and only if the object propertyP connectsI₂ withI₁.

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 asxsd:string orxsd: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 forn-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 Sections8.4 and8.5. The structure of data ranges in OWL 2 is shown in Figure 6. The simplest data ranges are datatypes. TheDataIntersectionOf,DataUnionOf, andDataComplementOf data ranges provide for the standard set-theoretic operations on data ranges; in logical languages these are usually called conjunction, disjunction, and negation, respectively. TheDataOneOf data range consists of exactly the specified set of literals. Finally, theDatatypeRestriction data range restricts the value space of a datatype by a constraining facet.

7.1 Intersection of Data Ranges

An intersection data rangeDataIntersectionOf( DR₁ ... DR_n ) contains all tuples of literals that are contained in each data rangeDR_i for 1 ≤ i ≤ n. All data rangesDR_iMUST 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 rangeDataUnionOf( DR₁ ... DR_n ) contains all tuples of literals that are contained in the at least one data rangeDR_i for 1 ≤ i ≤ n. All data rangesDR_iMUST 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 rangeDataComplementOf( DR ) contains all tuples of literals that are not contained in the data rangeDR. The resulting data range has the arity equal to the arity ofDR.

7.4 Enumeration of Literals

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

7.5 Datatype Restrictions

A datatype restrictionDatatypeRestriction( DT F₁ lt₁ ... F_n lt_n ) consists of a unary datatypeDT andn pairs( F_i , lt_i ). The resulting data range is unary and is obtained by restricting the value space ofDT according to the semantics of all( F_i , v_i ) (multiple pairs are interpreted conjunctively), wherev_i are the data values of the literalslt_i.

In an OWL 2 DL ontology, each pair( F_i , v_i )MUST be contained in the facet space ofDT (seeSection 4).

8 Class Expressions

In OWL 2, classes and property expressions are used to constructclass expressions, sometimes also calleddescriptions, 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 beinstances of the respective class expressions. In the structural specification of OWL 2, class expressions are represented byClassExpression.

OWL 2 provides a rich set of primitives that can be used to construct class expressions. In particular, it provides the well known Boolean connectivesand,or, andnot; a restricted form of universal and existential quantification; number restrictions; enumeration of individuals; and a specialself-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. TheObjectIntersectionOf,ObjectUnionOf, andObjectComplementOf class expressions provide for the standard set-theoretic operations on class expressions; in logical languages these are usually called conjunction, disjunction, and negation, respectively. TheObjectOneOf class expression contains exactly the specified individuals.

8.1.1 Intersection of Class Expressions

An intersection class expressionObjectIntersectionOf( CE₁ ... CE_n ) contains all individuals that are instances of all class expressionsCE_i for 1 ≤ i ≤ n.

8.1.2 Union of Class Expressions

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

8.1.3 Complement of Class Expressions

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

8.1.4 Enumeration of Individuals

An enumeration of individualsObjectOneOf( a₁ ... a_n ) contains exactly the individualsa_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. TheObjectSomeValuesFrom 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. TheObjectAllValuesFrom 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. TheObjectHasValue class expression contains those individuals that are connected by an object property expression to a particular individual. Finally, theObjectHasSelf class expression contains those individuals that are connected by an object property expression to themselves.

8.2.1 Existential Quantification

An existential class expressionObjectSomeValuesFrom( OPE CE ) consists of an object property expressionOPE and a class expressionCE, and it contains all those individuals that are connected byOPE to an individual that is an instance ofCE. Provided thatOPE issimple according to the definition inSection 11, such a class expression can be seen as a syntactic shortcut for the class expressionObjectMinCardinality( 1 OPE CE ).

8.2.2 Universal Quantification

A universal class expressionObjectAllValuesFrom( OPE CE ) consists of an object property expressionOPE and a class expressionCE, and it contains all those individuals that are connected byOPE only to individuals that are instances ofCE. Provided thatOPE issimple according to the definition inSection 11, such a class expression can be seen as a syntactic shortcut for the class expressionObjectMaxCardinality( 0 OPE ObjectComplementOf( CE ) ).

8.2.3 Individual Value Restriction

A has-value class expressionObjectHasValue( OPE a ) consists of an object property expressionOPE and an individuala, and it contains all those individuals that are connected byOPE toa. Each such class expression can be seen as a syntactic shortcut for the class expressionObjectSomeValuesFrom( OPE ObjectOneOf( a ) ).

8.2.4 Self-Restriction

A self-restrictionObjectHasSelf( OPE ) consists of an object property expressionOPE, and it contains all those individuals that are connected byOPE 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 toowl:Thing). The class expressionsObjectMinCardinality,ObjectMaxCardinality, andObjectExactCardinality 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 expressionObjectMinCardinality( n OPE CE ) consists of a nonnegative integern, an object property expressionOPE, and a class expressionCE, and it contains all those individuals that are connected byOPE to at leastn different individuals that are instances ofCE. IfCE is missing, it is taken to beowl:Thing.

8.3.2 Maximum Cardinality

A maximum cardinality expressionObjectMaxCardinality( n OPE CE ) consists of a nonnegative integern, an object property expressionOPE, and a class expressionCE, and it contains all those individuals that are connected byOPE to at mostn different individuals that are instances ofCE. IfCE is missing, it is taken to beowl:Thing.

8.3.3 Exact Cardinality

An exact cardinality expressionObjectExactCardinality( n OPE CE ) consists of a nonnegative integern, an object property expressionOPE, and a class expressionCE, and it contains all those individuals that are connected byOPE to exactlyn different individuals that are instances ofCE. IfCE is missing, it is taken to beowl: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 forn-ary data ranges. All data ranges explicitly supported by this specification are unary; however, the provision ofn-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, theDataSomeValuesFrom 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. TheDataAllValuesFrom 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, theDataHasValue 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 expressionDataSomeValuesFrom( DPE₁ ... DPE_n DR ) consists ofn data property expressionsDPE_i, 1 ≤ i ≤ n, and a data rangeDR whose arityMUST be n. Such a class expression contains all those individuals that are connected byDPE_i to literalslt_i, 1 ≤ i ≤ n, such that the tuple( lt₁ , ..., lt_n ) is inDR. A class expression of the formDataSomeValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expressionDataMinCardinality( 1 DPE DR ).

8.4.2 Universal Quantification

A universal class expressionDataAllValuesFrom( DPE₁ ... DPE_n DR ) consists ofn data property expressionsDPE_i, 1 ≤ i ≤ n, and a data rangeDR whose arityMUST be n. Such a class expression contains all those individuals that are connected byDPE_i only to literalslt_i, 1 ≤ i ≤ n, such that each tuple( lt₁ , ..., lt_n ) is inDR. A class expression of the formDataAllValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expressionDataMaxCardinality( 0 DPE DataComplementOf( DR ) ).

8.4.3 Literal Value Restriction

A has-value class expressionDataHasValue( DPE lt ) consists of a data property expressionDPE and a literallt, and it contains all those individuals that are connected byDPE tolt. Each such class expression can be seen as a syntactic shortcut for the class expressionDataSomeValuesFrom( 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 tordfs:Literal). The class expressionsDataMinCardinality,DataMaxCardinality, andDataExactCardinality 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 expressionDataMinCardinality( n DPE DR ) consists of a nonnegative integern, a data property expressionDPE, and a unary data rangeDR, and it contains all those individuals that are connected byDPE to at leastn different literals inDR. IfDR is not present, it is taken to berdfs: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 toSection 9.3.6.

8.5.2 Maximum Cardinality

A maximum cardinality expressionDataMaxCardinality( n DPE DR ) consists of a nonnegative integern, a data property expressionDPE, and a unary data rangeDR, and it contains all those individuals that are connected byDPE to at mostn different literals inDR. IfDR is not present, it is taken to berdfs: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 toSection 9.3.6.

8.5.3 Exact Cardinality

An exact cardinality expressionDataExactCardinality( n DPE DR ) consists of a nonnegative integern, a data property expressionDPE, and a unary data rangeDR, and it contains all those individuals that are connected byDPE to exactlyn different literals inDR. IfDR is not present, it is taken to berdfs: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 toSection 9.3.6.

9 Axioms

The main component of an OWL 2 ontology is a set ofaxioms — statements that say what is true in the domain. OWL 2 provides an extensive set of axioms, all of which extend theAxiom 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 calledfacts), and axioms about annotations.

As shown in Figure 1, OWL 2 axioms can contain axiom annotations, the structure of which is defined inSection 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. TheSubClassOf 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. TheEquivalentClasses axiom allows one to state that several class expressions are equivalent to each other. TheDisjointClasses axiom allows one to state that several class expressions are pairwise disjoint — that is, that they have no instances in common. Finally, theDisjointUnion 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 axiomSubClassOf( CE₁ CE₂ ) states that the class expressionCE₁ is a subclass of the class expressionCE₂. Roughly speaking, this states thatCE₁ is more specific thanCE₂. 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 axiomEquivalentClasses( CE₁ ... CE_n ) states that all of the class expressionsCE_i, 1 ≤ i ≤ n, are semantically equivalent to each other. This axiom allows one to use eachCE_i as a synonym for eachCE_j — that is, in any expression in the ontology containing such an axiom,CE_i can be replaced withCE_j without affecting the meaning of the ontology. An axiomEquivalentClasses( CE₁ CE₂ ) is equivalent to the following two axioms:

Axioms of the formEquivalentClasses( C CE ), whereC is a class andCE is a class expression, are often calleddefinitions, because they define the classC in terms of the class expressionCE.

9.1.3 Disjoint Classes

A disjoint classes axiomDisjointClasses( CE₁ ... CE_n ) states that all of the class expressionsCE_i, 1 ≤ i ≤ n, are pairwise disjoint; that is, no individual can be at the same time an instance of bothCE_i andCE_j for i ≠ j. An axiomDisjointClasses( CE₁ CE₂ ) is equivalent to the following axiom:

9.1.4 Disjoint Union of Class Expressions

A disjoint union axiomDisjointUnion( C CE₁ ... CE_n ) states that a classC is a disjoint union of the class expressionsCE_i, 1 ≤ i ≤ n, all of which are pairwise disjoint. Such axioms are sometimes referred to ascovering axioms, as they state that the extensions of allCE_i exactly cover the extension ofC. Thus, each instance ofC is an instance of exactly oneCE_i, and each instance ofCE_i is an instance ofC. 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. TheSubObjectPropertyOf axiom allows one to state that the extension of one object property expression is included in the extension of another object property expression. TheEquivalentObjectProperties axiom allows one to state that the extensions of several object property expressions are the same. TheDisjointObjectProperties 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. TheInverseObjectProperties axiom can be used to state that two object property expressions are the inverse of each other. TheObjectPropertyDomain andObjectPropertyRange 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.

TheFunctionalObjectProperty 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. TheInverseFunctionalObjectProperty 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, theReflexiveObjectProperty,IrreflexiveObjectProperty,SymmetricObjectProperty,AsymmetricObjectProperty, andTransitiveObjectProperty 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 isSubObjectPropertyOf( OPE₁ OPE₂ ). This axiom states that the object property expressionOPE₁ is a subproperty of the object property expressionOPE₂ — that is, if an individualx is connected byOPE₁ to an individualy, thenx is also connected byOPE₂ toy.

The more complex form isSubObjectPropertyOf( ObjectPropertyChain( OPE₁ ... OPE_n ) OPE ). This axiom states that, if an individualx is connected by a sequence of object property expressionsOPE₁, ...,OPE_n with an individualy, thenx is also connected withy by the object property expressionOPE. Such axioms are also known ascomplex role inclusions [SROIQ].

9.2.2 Equivalent Object Properties

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

9.2.3 Disjoint Object Properties

A disjoint object properties axiomDisjointObjectProperties( OPE₁ ... OPE_n ) states that all of the object property expressionsOPE_i, 1 ≤ i ≤ n, are pairwise disjoint; that is, no individualx can be connected to an individualy by bothOPE_i andOPE_j for i ≠ j.

9.2.4 Inverse Object Properties

An inverse object properties axiomInverseObjectProperties( OPE₁ OPE₂ ) states that the object property expressionOPE₁ is an inverse of the object property expressionOPE₂. Thus, if an individualx is connected byOPE₁ to an individualy, theny is also connected byOPE₂ tox, 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 axiomObjectPropertyDomain( OPE CE ) states that the domain of the object property expressionOPE is the class expressionCE — that is, if an individualx is connected byOPE with some other individual, thenx is an instance ofCE. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.6 Object Property Range

An object property range axiomObjectPropertyRange( OPE CE ) states that the range of the object property expressionOPE is the class expressionCE — that is, if some individual is connected byOPE with an individualx, thenx is an instance ofCE. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.7 Functional Object Properties

An object property functionality axiomFunctionalObjectProperty( OPE ) states that the object property expressionOPE is functional — that is, for each individualx, there can be at most one distinct individualy such thatx is connected byOPE toy. 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 axiomInverseFunctionalObjectProperty( OPE ) states that the object property expressionOPE is inverse-functional — that is, for each individualx, there can be at most one individualy such thaty is connected byOPE withx. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.9 Reflexive Object Properties

An object property reflexivity axiomReflexiveObjectProperty( OPE ) states that the object property expressionOPE is reflexive — that is, each individual is connected byOPE 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 axiomIrreflexiveObjectProperty( OPE ) states that the object property expressionOPE is irreflexive — that is, no individual is connected byOPE 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 axiomSymmetricObjectProperty( OPE ) states that the object property expressionOPE is symmetric — that is, if an individualx is connected byOPE to an individualy, theny is also connected byOPE tox. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.2.12 Asymmetric Object Properties

An object property asymmetry axiomAsymmetricObjectProperty( OPE ) states that the object property expressionOPE is asymmetric — that is, if an individualx is connected byOPE to an individualy, theny cannot be connected byOPE tox.

9.2.13 Transitive Object Properties

An object property transitivity axiomTransitiveObjectProperty( OPE ) states that the object property expressionOPE is transitive — that is, if an individualx is connected byOPE to an individualy that is connected byOPE to an individualz, thenx is also connected byOPE toz. 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. TheSubDataPropertyOf axiom allows one to state that the extension of one data property expression is included in the extension of another data property expression. TheEquivalentDataProperties allows one to state that several data property expressions have the same extension. TheDisjointDataProperties 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. TheDataPropertyDomain axiom can be used to restrict individuals connected by a property expression to be instances of the specified class; similarly, theDataPropertyRange axiom can be used to restrict the literals pointed to by a property expression to be in the specified unary data range. Finally, theFunctionalDataProperty 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 axiomSubDataPropertyOf( DPE₁ DPE₂ ) states that the data property expressionDPE₁ is a subproperty of the data property expressionDPE₂ — that is, if an individualx is connected byDPE₁ to a literaly, thenx is connected byDPE₂ toy as well.

9.3.2 Equivalent Data Properties

An equivalent data properties axiomEquivalentDataProperties( DPE₁ ... DPE_n ) states that all the data property expressionsDPE_i, 1 ≤ i ≤ n, are semantically equivalent to each other. This axiom allows one to use eachDPE_i as a synonym for eachDPE_j — that is, in any expression in the ontology containing such an axiom,DPE_i can be replaced withDPE_j without affecting the meaning of the ontology. The axiomEquivalentDataProperties( DPE₁ DPE₂ ) can be seen as a syntactic shortcut for the following axiom:

9.3.3 Disjoint Data Properties

A disjoint data properties axiomDisjointDataProperties( DPE₁ ... DPE_n ) states that all of the data property expressionsDPE_i, 1 ≤ i ≤ n, are pairwise disjoint; that is, no individualx can be connected to a literaly by bothDPE_i andDPE_j for i ≠ j.

9.3.4 Data Property Domain

A data property domain axiomDataPropertyDomain( DPE CE ) states that the domain of the data property expressionDPE is the class expressionCE — that is, if an individualx is connected byDPE with some literal, thenx is an instance ofCE. Each such axiom can be seen as a syntactic shortcut for the following axiom:

9.3.5 Data Property Range

A data property range axiomDataPropertyRange( DPE DR ) states that the range of the data property expressionDPE is the data rangeDR — that is, if some individual is connected byDPE with a literalx, thenx is inDR. The arity ofDRMUST 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 axiomFunctionalDataProperty( DPE ) states that the data property expressionDPE is functional — that is, for each individualx, there can be at most one distinct literaly such thatx is connected byDPE withy. Each such axiom can be seen as a syntactic shortcut for the following axiom: