Structural Reference Experiment

From OWL
Jump to: navigation, search

__NUMBEREDHEADINGS__

[Hide Review Comments]

Document title:
OWL 2 Web Ontology Language
Structural Specification and Functional-Style Syntax (Second Edition)
Authors
Boris Motik, Oxford University
Peter F. Patel-Schneider, Bell Labs Research, Alcatel-Lucent
Ian Horrocks, Oxford University
Abstract
The OWL 2 Web Ontology Language, informally OWL 2, is an ontology language for the Semantic Web with formally defined meaning. OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents. The OWL 2 Document Overview describes the overall state of OWL 2, and should be read before other OWL 2 documents.
This document defines the OWL 2 ontologies in terms of their structure, and it also defines a functional-style syntax in which ontologies can be written. Furthermore, this document provides an intuitive description of each of the constructs provided by the language.
Status of this Document
This document is an evolution of the OWL 1.1 Web Ontology Language: Structural Specification and Functional-Style Syntax document that forms part of the OWL 1.1 Web Ontology Language W3C Member Submission.

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

[Show Short TOC]

Contents

1 Introduction

Editor's Note: The document should say something about where it is normative, which I take to be something like, normative for structural specification, functional syntax, and imports; nonnormative for everything else, particularly for anything having to do with meaning and semantics.

This document defines the OWL 2 language. The core part of this specification is independent of the concrete exchange syntaxes for OWL 2 ontologies, as the language is defined by describing the conceptual structure of OWL 2 ontologies. This allows for a clear separation of the essential features of the language from issues related to any particular syntax. Furthermore, such a structural specification of OWL 2 provides the foundation for the implementation of OWL 2 tools such as APIs and reasoners.

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

Conceptually, OWL 2 ontologies are built from and using three different syntactic categories:

  • Entities, such as classes, properties, and individuals, are the things that are identified by URIs and can be thought of as primitive terms or names. For example, a class a:Person can be used to model the set of all people. Similarly, the object property a:parentOf can be used to model the fact that a person is a parent of another person. Finally, the individual a:Peter can be used to represent a particular person called "Peter".
  • Expressions are descriptive characterizations of entities. For example, a class expression defines a class in terms of the features that its instances must exhibit.
  • Axioms are statements that are deemed to be true in the domain being modeled. For example, using a subclass axiom, one can state that the class a:Student is a subclass of the class a:Person.

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

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

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

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

2 Basic Definitions

Editor's Note: See Issue-4 (syntax reordering).

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

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

2.1 Associations and Structural Equivalence

Many associations between components of OWL 2 ontologies are of one-to-many type; for example, an ObjectUnionOf class expression contains a set of disjuncts. Whether the components in the association are ordered and whether repetitions are allowed is made clear by the standard UML conventions:

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

Whether two ontology components are considered to be the same is captured by the notion of structural equivalence, defined as follows. Components o1 and o2 are structurally equivalent if the following conditions hold:

  • If o1 and o2 are atomic values, such as strings, integers, or IRIs (URIs), they are structurally equivalent if they are equal using equality for their atomic type — that is, if they are the same string, integer, or IRI.
  • If o1 and o2 are unordered associations without repetitions, they are structurally equivalent if each element of o1 is structurally equivalent to some element of o2 and vice versa.
  • If o1 and o2 are ordered associations with repetitions, they are structurally equivalent if they contain the same number of elements and each element of o1 is structurally equivalent to the element of o2 with the same index.
  • If o1 and o2 are complex components composed of other components, they are structurally equivalent if
    • both o1 and o2 are of the same type,
    • each component of o1 is structurally equivalent to the corresponding component of o2, and
    • each association of o1 is structurally equivalent to the corresponding association of o2.

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

Although set associations are widely used in the specification, sets written in one of the linear syntaxes (e.g., XML or RDF/XML) are not expected to be duplicate free; for example, an ontology written in functional-style syntax can contain a class expression of the form UnionOf( a:Person a:Animal a:Animal ). Duplicates should be eliminated from such sets during parsing.

2.2 URIs and Namespaces

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

CURIEs [CURIE] are used for abbreviating long IRIs.

curie := [ [ prefix ] ':' ] reference
prefix := nc-name
reference := irelative-ref
irelative-ref := as defined in [RFC-3987]
nc-name := as defined in [XML Namespaces]

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

full-IRI := '<' IRI as defined in [RFC-3987] '>'
abbreviated-IRI := curie
URI := full-IRI | abbreviated-IRI

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

Editor's Note: The actual namespaces used in the specification are subject to discussion and might change in future.

Table 1 defines the standard namespaces and the respective prefixes used throughout this specification. The URIs with these name namespaces are said to constitute the reserved vocabulary of OWL 2. As described in the following sections, URIs from the reserved vocabulary have special treatment and are used internally by OWL 2.

2.3 Integers, Strings, Language Tags, and Node IDs

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

zero := '0'
nonZero  := '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
digit := zero | nonZero
postiveInteger := nonzero { digit }
nonNegativeInteger := zero | positiveInteger

Strings are sequences of Unicode characters. In the functional-style syntax, strings are enclosed in double quotes; in order to allow for strings that contain the quotation character, OWL 2 employs a quoting mechanism that is a subset of the one used in the N-triples specification [RDF Test Cases].

quotedString := '"' a Unicode string in normal form C [UNICODE] with double quotes and backslashes replaced by the double quote or backslash preceded by a backslash '"'

Language tags are borrowed from [RFC-4646].

languageTag := a language tag as specified in [RFC-4646]

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

nodeID := a node ID for the form _:name as specified in the N-Triples specification [RDF Test Cases]

3 Ontologies

Editor's Note: See Issue-21 (import-target-match) and Issue-24 (1-version-allowed-policy).

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

OWL Ontologies
Figure 1. OWL Ontologies

 xmlAttrs =
 attribute id { xsd:ID }?,
 attribute space { xsd:NCName "preserve" | xsd:NCName "default" }?,
 attribute lang { xsd:language | xsd:string "" }?,
 attribute base { xsd:anyURI }?
 
Ontology = element Ontology {
        xmlAttrs,
        attribute owlx:ontologyURI { xsd:anyURI }?,
        Imports*,
        Annotation*,
        Axiom*
}

 Imports = element Imports { specialAttrs, xsd:anyURI }

 Annotation =
       notAllowed
       | element Annotation {
                    specialAttrs, AnnotationProperty, (Constant | OWLEntity)
          }
       | Label
       | Comment
  }

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

The following is an ontology with a URI http://example.org/ontology1 that imports an ontology http://example.org/ontology2 and that contains an ontology annotation that provides a label for the ontology and a single subclass axiom.

Ontology(<http://example.org/ontology1>
    Import(<http://example.org/ontology2>)
    Label("The example")

    SubClassOf( a:Child a:Person )
)

3.1 Ontology URI and Version URI

Each ontology can have an ontology URI, which is used to uniquely identify an ontology. If an ontology has an ontology URI, the ontology can additionally have a version URI, which is used to identify the version of the ontology. The version URI can, but need not be equal to the ontology URI.

The uniqueness of the ontology and the version URIs is governed by the following conventions.

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

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

The ontology URI and the version URI together identify a particular version from an ontology series — a set of all versions of a particular ontology identified using the common ontology URI. Structurally, a version of a particular ontology is an instance of the Ontology from the structural specification. The structural specification does NOT explicitly contain an object corresponding to the ontology series; therefore, an ontology series is an informal term that exists only as a side-effect of the naming conventions described in this and the following sections.

3.2 Physical Locations of OWL 2 Ontologies

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

  • If O does not contain an ontology URI (and, consequently, without a version URI as well), then O can be physically located anywhere.
  • If O contains an ontology URI ou but no version URI, then O should be physically located at the location ou.
  • If O contains an ontology URI ou and a version URI vu, then O should be physically located at the location ou or vu.

Thus, the most recent version of an ontology series with some URI ou can be obtained from ou using a suitable (Internet) protocol. To access a particular version of ou, one must know that version's version URI vu; then, the ontology can be obtained from vu using a suitable (Internet) protocol. When opening an ontology form a location u, OWL 2 tools should check whether u matches the ontology or the version URI according to the mentioned three constraints.

An ontology O containing an ontology URI http://www.my.com/example but no version URI should be physically located at the address http://www.my.com/example. In contrast, an ontology O' containing an ontology URI http://www.my.com/example and a version URI http://www.my.com/example/2.0/ should be physically located at the address http://www.my.com/example/2.0/. In both cases, the ontology should be retrievable from the respective addresses using the HTTP protocol.

OWL 2 tools will often need to implement functionality such as caching or off-line processing, where the physical location of stored ontologies differs from their permanent locations (as dictated by the ontology URI and the version URI). In such cases, OWL 2 may implement a location redirection mechanism: when the user requests to open an ontology at location u, the tool can translate u to a different location u' and access the ontology from there. Once the ontology is retrieved, however, it should satisfy the tree conditions from the beginning of this section in the same way as if it were truly retrieved from u. This document does not specify any particular location redirection mechanisms — these are assumed to be implementation dependent.

To enable off-line processing, an ontology O containing an ontology URI http://www.my.com/example might be stored in a file with a location file:/C:/Temp/example.owl. When opening an ontology with a URI http://www.my.com/example in an OWL 2 tool, the tool can redirect this URI to file:/C:/Temp/example.owl and retrieve the ontology from there. The retrieved ontology should satisfy the location constraints: if the ontology contains only the ontology URI, then the ontology URI should be equal to http://www.my.com/example, and if the ontology contains both the ontology and the version URI, then one of them should be equal to http://www.my.com/example.

3.3 Versioning of OWL 2 Ontologies

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

The current version of an ontology series might be located at a URI http://www.my.com/example, as well as the location http://www.my.com/example/2.0/ for the particular version. When a new version is created, the previous version should remain accessible at http://www.my.com/example/2.0/; the new version, called, say, http://www.my.com/example/3.0/, would be placed at locations http://www.my.com/example/ and http://www.my.com/example/3.0/.

3.4 Imports

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

Assume that one wants to describe research projects about diseases. Managing information about the projects and the diseases in the same ontology might be cumbersome. Therefore, one might create a separate ontology O about diseases and a separate ontology O' about projects. The ontology O' would import O in order to gain access to the classes representing diseases; intuitively, this allows one to use the diseases from O when writing the axioms of O'.

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

Assume that an ontology O logically imports another ontology O', which has the ontology URI http://www.my.com/example/ and the version URI http://www.my.com/example/2.0/. In a concrete syntax, O would contain the location of O'; in the functional-style syntax, O would be written as follows.

Ontology(<http://example.org/importing-ontology>
    Import(<http://www.my.com/example/2.0/>)

...
)

The location of the imported ontology can be redirected, as described in Section 3.2. For example, the ontology http://www.my.com/example/2.0/ might be physically stored at location file:/C:/Temp/imported.v20.owl. Location redirection can thus be used to work with ontologies locally without the need for editing the ontologies and fixing the import relationships between them.

The version of the imported ontology O' is fully determined by the URI occurring in the import specification of the importing ontology O. In the previous example, O specified a location of a particular version of O'. In contrast, the following ontology imports the most recent version of http://www.my.com/example/.

Ontology(<http://example.org/importing-ontology>
    Import(<http://www.my.com/example/>)

...
)

The OWL 2 specification provides no means for checking whether O is compatible with the actually imported ontology versions. Furthermore, if the ontologies imported into O additionally import other ontologies, it is possible for O to import two different, possibly incompatible, versions from the same ontology series. OWL 2 provides no built-in means for detecting such situations. Extensions providing such a mechanism, however, can be implemented on top of OWL 2 import mechanism presented here.

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

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

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

3.5 Ontology Annotations

An OWL 2 ontology contains a set of annotations. These can be used to associate nonlogical information with an ontology, such as the name of the ontology creator or the version of the ontology. As discussed in Section 9 in more detail, each annotation consists of an annotation property and an annotation value, and the latter can be a constant, an entity, or an anonymous individual. Ontology annotations do not affect the logical meaning of the ontology; rather, their values can be used by OWL 2, for example, for managing information about an ontology.

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

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

4 Entities and Constants

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 constants, such as strings or integers.

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

The Hierarchy of Entities in OWL 2
Figure 2. The Hierarchy of Entities in OWL 2

4.1 Classes

Classes can be understood as sets of individuals.

OWLClass =
  element OWLClass {
     xmlAttrs,
     attribute owlx:URI { xsd:anyURI }
   }

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

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

Classes a:Child and a:Person can be used to model the set of all children and persons, respectively, in the application domain, and they can be used in an axiom such as the following one:

SubClassOf( a:Child a:Person ) a:Child is a subclass of a:Person.

4.2 Datatypes

Editor's Note: The architecture of the datatype system and, in particular, the set of supported datatypes are likely to change in future releases of this specification.

Datatypes are tuples of data values, such as strings or integers, identified using URIs. Each datatype is associated with a positive, nonzero arity, which specifies the size of a tuples contained in the datatype; furthermore, two datatypes cannot share the same URI but differ in the arity. OWL 2 supports a number of built-in datatypes.

  • OWL 2 supports the unary datatype rdfs:Literal, which is interpreted as the set of all data values.
  • The unary datatype owl:internationalizedString represents pairs of strings and language tags, and thus represents plain RDF literals with a language tag. The lexical space of this datatype is a string of the form "text@languageTag"; thus, the text of each lexical value before last @ sign is the actual text, and the text after the last @ sign is the language tag of the constant. Each such lexical value is interpreted as a pair <"text",languageTag>.

Implementations of OWL 2 can extend the set of supported datatypes: the semantics of OWL 2 is defined in a way such that the interpretation of an ontology does not depend on the set of supported datatypes. The structural specification of OWL 2 allows for n-ary datatypes in order to accommodate such extensions. The URIs used to identify such datatypes are not allowed to be in the reserved vocabulary.

OWL 2 provides a facility for restricting a datatype to a subset of its values; for example, one can define the set of integers between one and five inclusive. The datatype restrictions are described in more detail in Section 6.3.

Datatype =
  element Datatype {
     xmlAttrs,
     attribute owlx:arity { xsd:positiveInteger }?,
     attribute owlx:URI { xsd:anyURI }
   }

4.3 Object Properties

Object properties associate pairs of individuals. URIs used to identify object properties should not be in the reserved vocabulary.

ObjectProperty =
  element ObjectProperty {
     xmlAttrs,
     attribute owlx:URI { xsd:anyURI }
   }

The object property a:parentOf can be used to represent the parenthood relationship between individuals, and it can be used in the axioms such as the following one:

PropertyAssertion( a:parentOf a:Peter a:Chris ) a:Peter is a parent of a:Chris.

4.4 Data Properties

Data properties associate individuals with constants. In some knowledge representation systems, functional data properties are called attributes. URIs used to identify data properties should not be in the reserved vocabulary.

DataProperty =
  element DataProperty {
     xmlAttrs,
     attribute owlx:URI { xsd:anyURI }
   }

The data property a:name can be used to associate a name with each person, and it can be used in the axioms such as the following one:

PropertyAssertion( a:name a:Peter "Peter Griffin" ) The a:name of a:Peter is "Peter Griffin".

4.5 Annotation Properties

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

AnnotationProperty =
  element AnnotationProperty {
     xmlAttrs,
     attribute owlx:URI { xsd:anyURI }
   }

URIs used to identify annotation properties should not be in the reserved vocabulary; furthermore, the following URIs from the reserved vocabulary are built-in annotation properties that can be used in OWL 2.

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

The well-known annotation property rdfs:comment can be used to associate a comment with ontology entities. It can be used in axioms such as the following one (in this axiom, the annotation is represented using the abbreviated syntax):

EntityAnnotation( NamedIndividual ( a:Peter )
    Comment( "The father of the Griffin family from Quahog." )
)
This axiom provides a comment for the individual a:Peter.

4.6 Individuals

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

Individual := NamedIndividual | AnonymousIndividual

4.6.1 Named Individuals

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

Individual =
element Individual {
     xmlAttrs,
     attribute owlx:URI { xsd:anyURI }
   }

The individual a:Peter can be used to represent a particular person, and it can be used in axioms such as the following one:

ClassAssertion( a:Person a:Peter ) a:Peter is an instance of a:Person.
4.6.2 Anonymous Individuals

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

AnonymousIndividual := nodeID

Anonymous individuals can be used, for example, to represent objects whose identity is of no relevance, such as the address of a person.

PropertyAssertion( a:livesAt a:Peter _:1 ) a:Peter lives at some address, represented using the anonymous individual _:1.
PropertyAssertion( a:city _:1 a:Quahog ) The object represented by the anonymous individual _:1 is related to individual a:Quahog by the property a:city.
PropertyAssertion( a:state _:1 a:RI ) The object represented by the anonymous individual _:1 related to individual a:RI (representing the state of Rhode Island) by the property a:state.

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

Assume that ontologies O1 and O2 both use _:a5, and that O1 imports O2. Intuitively, within O1 and O2, each occurrence of _:a5 refers to the same individual; however, the individual _:a5 in O1 may be different from the individual _:a5 in O2.

At the level of the structural specification, individual _:a5 in O1 is structurally equivalent to individual _:a5 in O2. This might be important, for example, for tools that use structural equivalence to define semantics of axiom retraction: in such a case, there is no distinguishing axioms containing either version of individual _:a5.

That these individuals are treated differently by the semantics is achieved by renaming them apart when computing the axiom closure of O1either _:a5 must be replaced in O1 with a fresh anonymous individual, or this must be done for _:a5 in O2.

4.7 Constants

Constants represent data values, such as particular strings or integers, and are analogous to constants in RDF [RDF Syntax]. Each constant consists of its lexical value, which is simply a Unicode string, and a datatype specifying the type of a constant, which identifies the allowed formats of lexical values as well as their interpretation.

The functional-style syntax provides for two abbreviations for writing constants (the constants of these types can be also written in the original, unabbreviated form):

  • The type for constants of datatype xsd:string can be omitted.
  • The constants of datatype owl:internationalizedString can be written simply as "lexical value"@language.

lexicalValue := quotedString
stringConstant := lexicalValue
internationalizedStringConstant := lexicalValue '@' languageTag
typedConstant := lexicalValue '^^' Datatype
Constant := stringConstant | internationalizedStringConstant | typedConstant

"1"^^xsd:integer is a constant that represents the integer data value 1.

"Family Guy" is an abbreviation for "Family Guy"^^xsd:string — a constant with value "Family Guy" and type xsd:string,

"Padre de familia"@es is an abbreviation to an internationalized constant "Padre de familia@es"^^xsd:internationalizedString — that is, a pair consisting of the string "Padre de familia" and the language tag es denoting the Spanish language. Note that the lexical values of xsd:internationalizedString constants are strings that contain the actual string value, the @ sign, and the language tag, without any spaces between them.

4.8 Referring to Entities in Functional-Style Syntax

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

OWLEntity =
 Datatype
 | OWLClass
 | ObjectProperty
 | DataProperty
 | AnnotationProperty
 | Individual

4.9 Entity Declarations and Typing

All entities apart from datatypes can, and sometimes even must, be declared in an OWL 2 ontology. A declaration for an entity with a URI u in an ontology O serves two purposes:

  • A declaration says that u exists — that is, it says that u is part of the vocabulary of O. For example, an ontology editor can use declarations to implement functions such as "Add New Class".
  • A declaration associates u with an entity type — that is, declarations say whether u is a class, datatype, object property, data property, annotation property, an individual, or a combination thereof.

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

In OWL 2, declarations are a type of axioms; thus, to declare an entity in an ontology, one can simply include the appropriate axiom into the ontology. These axioms are nonlogical in the sense that they do not affect the meaning of an ontology [OWL 2 Semantics]. Declarations have been defined as a kind of axiom in order to unify the structural specification: if declarations were not axioms, an ontology would need to consist of a set of axioms and a set of declarations, which would just make the specification more complex. The structure of entity declarations is shown in Figure 3.

Entity Declarations in OWL 2
Figure 3. Entity Declarations in OWL 2

Declaration := 'Declaration' '(' { Annotation } Entity ')'

The following axioms declare a:Person to be a class and a:Peter to be an individual.

Declaration( Class( a:Person ) )
Declaration( NamedIndividual( a:Peter ) )

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

Table 2. Declarations of Built-In Entities
Declaration( Class( owl:Thing ) )
Declaration( Class( owl:Nothing ) )
Declaration( Datatype( u 1 ) ) for each URI u of a datatype listed in Section 4.2
Declaration( AnnotationProperty( u ) ) for each URI u of a built-in annotation property listed in Section 4.5
4.9.1 Typing Constraints

A URI u is declared as having type T in an OWL 2 ontology O if a declaration axiom of type T for u is contained in the axiom closure of O or in the set of built-in declarations listed in Table 2.

Each ontology O must satisfy the following typing constraints:

  • If a URI u is used in O in an axiom in the position of an object, data, or annotation property, then O must uniquely declare u as either an object, data, or an annotation property; that is, O should not declare u as a combination of these types.
  • If a URI u is used in O in an axiom in the position of a class or a datatype, then O must uniquely declare u as either a class or a datatype; that is, O should not declare u as a combination of these types.
  • No URI u should be declared in O as two datatypes with the same URI but different arities.
  • No declaration for a URI u should violate the constraints on the usage of reserved vocabulary listed in the previous section.

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

All other declarations are optional; for example, a URI u can be used as an individual in O even if u is not declared as an individual in O.

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

4.9.2 Declaration Consistency

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

The following ontology erroneously refers to the class a:Persno instead the class a:Person.

Ontology(<http://www.my.domain.com/example>
    ClassAssertion( a:Persno a:Peter )
)

There is no way of telling whether a:Persno is a valid class or whether it was used by mistake. If, in contrast, all classes in an ontology were by convention required to be declared, this error could be caught by a simple tool.

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

The ontology from the previous example fails this check: a:Peter is used as an individual but the ontology does not declare a:Peter to be an individual, and similarly for a:Persno. In contrast, the following ontology satisfies this condition.

Ontology(<http://www.my.domain.com/example>
    Declaration( Class( a:Person ) )
    Declaration( NamedIndividual( a:Peter ) )
    ClassAssertion( a:Person a:Peter )
)

4.9.3 Declarations and Parsing

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

A parser might encounter the following axiom:

SubClassOf ( a:Father SomeValuesFrom( a:parentOf a:Child ) )

From this axiom alone, it is not clear whether a:parentOf is an object or a data property, and whether a:Child is a class or a datatype. In order to disambiguate the types of these URIs, the parser must look at the declarations in the axiom closure of the ontology being parsed.

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

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

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

It is important to understand that canonical parsing merely defines the result of the parsing process, and that a smart implementation of OWL 2 can optimize this process in numerous ways. For example, if the declarations for the URIs are always located in the text of O physically before the URIs are used, a "smart" OWL 2 parser can parse the ontology in a single pass. In order to enable efficient parsing, OWL 2 implementations are encouraged to write ontologies into documents by placing all URI declarations before the axioms that use these URIs; however, this is not required for conformance. As another example, a "smart" OWL 2 parser can optimize the handling of imported ontologies in cases when the import relation between the ontologies is acyclic.

In some cases, it is possible to infer the existence of missing declarations. In the previous example, if a:Child were declared as a class, the only way for the ontology to make sense is if a:parentOf were declared to be an object property. An OWL 2 implementation MAY repair such ontologies by adding missing declarations. The precise repair process is not covered by this specification. If repair is applied, the resulting ontology must satisfy the typing constraints from Section 4.9.1; that is, the missing declarations must be actually added to the ontology.

5 Property Expressions

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

5.1 Object Property Expressions

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

Object Property Expressions
Figure 4. Object Property Expressions

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

ObjectPropertyExpression := ObjectProperty | InverseObjectProperty

5.1.1 Inverse Object Properties

An inverse object property expression InverseOf( P ) contains exactly those pairs of individuals <I1,I2> such that <I2,I1> are contained in the object property P.

InverseObjectProperty := 'InverseOf' '(' ObjectProperty ')'

Consider the ontology consisting of the following assertion.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:Peter is the father of a:Stewie.

This ontology entails that a:Stewie is connected through InverseOf( a:fatherOf ) to a:Peter.

5.2 Data Property Expressions

For symmetry with object property expressions, the structural specification of OWL 2 also introduces the notion of data property expressions, as shown in Figure 9. As one can see, 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.

Data Property Expressions
Figure 5. Data Property Expressions

DataPropertyExpression := DataProperty

6 Data Ranges

Editor's Note: See Issue-5 (n-ary datatypes), Issue-31 (XSD defined datatypes), Issue-53 (Linear inequality between two data types), and Issue-71 (datarange language range).
Review comment from MikeSmith 06:44, 26 November 2007 (EST)
Text addressing ISSUE-31: "Canonical URI for externally defined datatypes" is provided on the discussion page and proposed for inclusion here.

Datatypes, such as strings or integers, can be used to express data ranges — sets of tuples of data values. Data ranges can be used in restrictions on data properties, as discussed in Sections 7.4 and 7.5. The structure of data ranges in OWL 2 is shown in Figure 6. The simplest data ranges are datatypes. The DataComplementOf data range consists of all data values that are not in the specified data range. The nominal DataOneOf data range consists exactly the specified set of data values. Finally, the DatatypeRestriction data ranges are obtained by restricting an existing data type to a subset of its values.

Data Ranges in OWL 2
Figure 6. Data Ranges in OWL 2

DataRange :=
    Datatype |
    DataComplementOf |
    DataOneOf |
    DatatypeRestriction

6.1 Complement of Data Ranges

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

DataComplementOf := 'ComplementOf' '(' DataRange ')'

The complement data range ComplementOf( xsd:positiveInteger ) consists of data values that are not positive integers. In particular, this data range contains the integer zero and all negative integers; however, it also contains all strings (since strings are not positive integers).

6.2 Enumerated Data Ranges

An enumerated data range OneOf( C1 ... Cn ) contains all data values that correspond to the constants Ci with 1 ≤ i ≤ n.

DataOneOf := 'OneOf' '(' Constant { Constant } ')'

The enumerated data range OneOf( "Peter" "1"^^xsd:integer ) contains exactly two data values: the string "Peter" and the integer one.

6.3 Datatype Restrictions

A datatype restriction DatatypeRestriction( DT F1 C1 ... Fn Cn ) consists of a unary datatype DT and n facet-constant pairs < Fi, Ci >, where facet can be one of length, minLength, maxLength, pattern, minInclusive, minExclusive, maxInclusive, maxExclusive, totalDigits, and fractionDigits. The resulting data range is unary and it consists of the values of DT restricted according to the semantics of facets as specified in [XML Schema Datatypes] (multiple facets are interpreted conjunctively).

Not all datatypes are compatible with all facets; Table 3 lists the allowed combinations.

Table 3. Compatibility Between Datatypes and Facets
Datatype Allowed Facets
xsd:boolean pattern
xsd:decimal, xsd:double, xsd:float,
xsd:long, xsd:integer, xsd:int, xsd:short, xsd:byte,
xsd:nonPositiveInteger, xsd:nonNegativeInteger,
xsd:positiveInteger, xsd:negativeInteger,
xsd:unsignedLong, xsd:unsignedInt,
xsd:unsignedShort, xsd:unsignedByte
minInclusive, minExclusive,
maxInclusive, maxExclusive,
totalDigits, fractionDigits,
pattern
xsd:dateTime, xsd:time, xsd:date,
xsd:gYear, xsd:gMonth, xsd:gDay,
xsd:gYearMonth, xsd:gMonthDay
minInclusive, minExclusive,
maxInclusive, maxExclusive,
pattern
xsd:string, xsd:normalizedString, xsd:anyURI,
xsd:token, xsd:language, xsd:NMTOKEN,
xsd:Name, xsd:NCName,
xsd:hexBinary, xsd:base64Binary
length, minLength, maxLength,
pattern

facet :=
    'length' | 'minLength' | 'maxLength' | 'pattern' |
    'minInclusive' | 'minExclusive' | 'maxInclusive' | 'maxExclusive' |
    'totalDigits' | 'fractionDigits'
restrictionValue := Constant
DatatypeRestriction := 'DatatypeRestriction' '(' Datatype facet restrictionValue { facet restrictionValue } ')'

The data range DatatypeRestriction( xsd:integer minInclusive "5"^^xsd:integer maxExclusive "10"^^xsd:integer ) contains exactly the integers 5, 6, 7, 8, and 9.

7 Class Expressions

In OWL 2, classes and property expressions can be used to construct class expressions, sometimes also called descriptions, and, in the description logic literature, complex concepts. Just like classes, class expressions are sets of individuals; the main difference is that class expressions formally specify conditions [OWL 2 Semantics] that individuals must satisfy in order to be instances of the class expression. For example, one can use a class expression to model the set of "people that have at least child". These conditions can be used to classify individuals in an ontology as instances of class expressions. For example, if an ontology contains statements that "Peter is a person" and that "Peter has child Chris", then Peter can be classified as an instance of the mentioned class expression. 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 (i.e., propositional) connectives and, or, and not, a restricted form of universal and existential quantification, number restrictions, nominals, and a special self-restriction.

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

ClassExpression :=
    Class |
    ObjectIntersectionOf | ObjectUnionOf | ObjectComplementOf | ObjectOneOf |
    ObjectSomeValuesFrom | ObjectAllValuesFrom | ObjectHasValue | ObjectExistsSelf |
    ObjectMinCardinality | ObjectMaxCardinality | ObjectExactCardinality |
    DataSomeValuesFrom | DataAllValuesFrom | DataHasValue |
    DataMinCardinality | DataMaxCardinality | DataExactCardinality

7.1 Propositional Connectives and Nominals

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

Propositional Connectives and Nominals
Figure 7. Propositional Connectives and Nominals

7.1.1 Intersection

An intersection class expression IntersectionOf( CE1 ... CEn ) contains all individuals that are instances of all class expressions CEi for 1 ≤ i ≤ n.

ObjectIntersectionOf := 'IntersectionOf' '(' ClassExpression ClassExpression { ClassExpression } ')'

Consider the ontology consisting of the following axioms.

ClassAssertion( a:Dog a:Brian ) a:Brian is a dog.
ClassAssertion( a:CanTalk a:Brian ) a:Brian can talk.

The class expression IntersectionOf( a:Dog a:CanTalk ) describes all dogs that can talk and, consequently, a:Brian is classified as its instance.

7.1.2 Union

A union class expression UnionOf( CE1 ... CEn ) contains all individuals that are instances of at least one class expression CEi for 1 ≤ i ≤ n.

ObjectUnionOf := 'UnionOf' '(' ClassExpression ClassExpression { ClassExpression } ')'

Consider the ontology consisting of the following axioms.

ClassAssertion( a:Man a:Peter ) a:Peter is a man.
ClassAssertion( a:Woman a:Lois ) a:Lois is a woman.

The class expression UnionOf( a:Man a:Woman ) describes all things that are instances of either a:Man or a:Woman; consequently, both a:Peter and a:Lois are classified as instances of this expression.

7.1.3 Complement

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

ObjectComplementOf := 'ComplementOf' '(' ClassExpression ')'

Consider the ontology consisting of the following axioms.

DisjointClasses( a:Man a:Woman ) No object can be both a man and a woman.
ClassAssertion( a:Woman a:Lois ) a:Lois is a woman.

The class expression ComplementOf( a:Man ) describes all things that are not instances of either a:Man. Since a:Lois is known to be a woman, and nothing can be both a man and a woman, then a:Lois is necessarily not a a:Man; therefore, a:Lois is classified as an instance of this complement class expression.

OWL 2 employs the open-world assumption, so negation in OWL 2 is the same as in classical (first-order) logic. To understand the open-world assumption, Consider the ontology consisting of the following assertion.

ClassAssertion( a:Dog a:Brian ) a:Brian is a dog.

One might intuitively expect a:Brian to be classified as an instance of ComplementOf( a:Bird ): the ontology does not explicitly state that a:Brian is an instance of a:Bird, so this statement seems to be false. In OWL 2, however, this is not the case: it is true that the ontology does not state that a:Brian is an instance of a:Bird; however, the ontology does not state the opposite either. In other words, this ontology simply does not contain enough information to answer the question whether a:Brian is an instance of a:Bird or not: it is perfectly possible that the information to that effect bird is actually true but it has not been included into the ontology (hence the name "open-world assumption").

The ontology from the previous example (in which a:Lois has been classified as a:Man), however, contains sufficient information to draw the expected conclusion. In particular, we know for sure that a:Lois is an instance of a:Woman and that a:Man and a:Woman do not share instances. Therefore, any additional information that does not lead to inconsistency cannot make us conclude that a:Lois is a:Man; furthermore, if one were to explicitly state that a:Lois is an instance of a:Man, the ontology would be inconsistent and, by definition, it then entails all possible conclusions.

7.1.4 Nominals

A nominal class expression OneOf( I1 ... In ) contains exactly the individuals Ii with 1 ≤ i ≤ n.

ObjectOneOf := 'OneOf' '(' Individual { Individual }')'

Consider the ontology consisting of the following axioms.

EquivalentClasses( a:GriffinFamily
    OneOf( a:Peter a:Lois a:Stewie a:Meg a:Chris a:Brian )
)
The Griffin family consists exactly of Peter, Lois, Stewie, Meg, and Brian.
DifferentIndividuals( a:Quagmire a:Peter a:Lois a:Stewie a:Meg a:Chris a:Brian ) All these individuals are different from each other.

The class a:GriffinFamily now contains exactly the named five individuals. Since we also know that a:Quagmire is different from these six individuals, it is classified as an instance of ComplementOf( a:GriffinFamily ). Due to the open-world assumption, the last axiom is necessary to derive this conclusion; without it, the semantics of OWL 2 would take into account that a:Quagmire might be the same as a:Peter, a:Lois, a:Stewie, a:Meg, a:Chris, or a:Brian.

To understand how the open-world assumption affects nominals, consider the ontology consisting of the following axioms.

ClassAssertion( a:GriffinFamily a:Peter ) a:Peter is a member of the Griffin Family.
ClassAssertion( a:GriffinFamily a:Lois ) a:Lois is a member of the Griffin Family.
ClassAssertion( a:GriffinFamily a:Stewie ) a:Stewie is a member of the Griffin Family.
ClassAssertion( a:GriffinFamily a:Meg ) a:Meg is a member of the Griffin Family.
ClassAssertion( a:GriffinFamily a:Chris ) a:Chris is a member of the Griffin Family.
ClassAssertion( a:GriffinFamily a:Brian ) a:Brian is a member of the Griffin Family.

The class a:GriffinFamily now also contains the mentioned six individuals, just as in the previous example. The main difference to the previous example, however, is that the extension of a:GriffinFamily is not closed: the semantics of OWL 2 assumes that information about a potential instance of a:GriffinFamily may be missing. Therefore, a:Quagmire is now NOT classified as an instance of ComplementOf( a:GriffinFamily ), and this does not change even if we add the axiom stating that all of these six individuals are different from each other.

7.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 a restricted existential quantification over an object property expression, and it contains those individuals that are connected through an object property expression to an instance of a given class expression. The ObjectAllValuesFrom class expression allows for a restricted 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 ObjectExistsSelf class expression contains those individuals that are connected by an object property expression to a particular individual.

Restricting Object Property Expressions
Figure 8. Restricting Object Property Expressions

7.2.1 Existential Quantification

An existential class expression SomeValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and contains all those individuals that are connected by OPE to an individual that is an instance of CE.

ObjectSomeValuesFrom := 'SomeValuesFrom' '(' ObjectPropertyExpression ClassExpression ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:Peter is the father of a:Stewie.
ClassAssertion( a:Man a:Stewie ) a:Stewie is a man.

The existential expression SomeValuesFrom( a:fatherOf a:Man ) contains those individuals that are connected by the a:fatherOf property to individuals that are instances of a:Man and, consequently, a:Peter is classified as an instance of this class expression.

7.2.2 Universal Quantification

A universal class expression AllValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and contains all those individuals that are connected by OPE only to individuals that are instances of CE.

ObjectAllValuesFrom := 'AllValuesFrom' '(' ObjectPropertyExpression ClassExpression ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasPet a:Peter a:Brian ) a:Peter has a:Brian as a pet.
ClassAssertion( a:Dog a:Brian ) a:Brian is a dog.
ClassAssertion( MaxCardinality( 1 a:hasPet ) a:Peter ) a:Peter has at most one thing as a pet.

The universal expression AllValuesFrom( a:hasPet a:Dog ) contains those individuals that are connected through the a:hasPet property only with individuals that are instances of a:Dog; in other words, it contains individuals that have only dogs as pets. The ontology axioms clearly state that a:Peter is connected by a:hasPet only to instances of a:Dog: it is impossible to add further information to the ontology without making the ontology inconsistent. Therefore, a:Peter is classified as an instance of AllValuesFrom( a:hasPet a:Dog ).

The last axiom — that is, the axiom stating that a:Peter has at most one pet — is critical for the inference from the previous paragraph due to the open-world assumption of OWL 2. Without this axiom, the ontology might not have listed all the individuals to which a:Peter is connected by a:hasPet. In such a case a:Peter would NOT be classified as an instance of AllValuesFrom( a:hasPet a:Dog ).

7.2.3 Restriction to an Individual

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

SomeValuesFrom( OPE OneOf( I ) ).

ObjectHasValue := 'HasValue' '(' ObjectPropertyExpression Individual ')'

Consider the ontology consisting of the following axiom.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:Peter is the father of a:Stewie.

The has-value class expression HasValue( a:fatherOf a:Stewie ) contains those individuals that are connected through the a:fatherOf property with the individual a:Stewie so, consequently, a:Peter is classified as an instance of this class expression.

7.2.4 Self-Restriction

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

ObjectExistsSelf := 'ExistsSelf' '(' ObjectPropertyExpression ')'

Consider the ontology consisting of the following axiom.

PropertyAssertion( a:likes a:Peter a:Peter ) a:Peter likes himself.

The self-restriction ExistsSelf( a:likes ) contains those individuals that like themselves so, consequently, a:Peter is classified as an instance of this class expression.

7.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, depending on whether there is a restriction on the class expression that the connected individuals must be instances of. An unqualified cardinality restriction is equivalent to a qualified one where the restricting class expressions is 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.

Restricting the Cardinality of Object Property Expressions
Figure 9. Restricting the Cardinality of Object Property Expressions

7.3.1 Minimum Cardinality

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

ObjectMinCardinality := 'MinCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:Peter is the father of a:Stewie.
ClassAssertion( a:Man a:Stewie ) a:Stewie is a man.
PropertyAssertion( a:fatherOf a:Peter a:Chris ) a:Peter is the father of a:Chris.
ClassAssertion( a:Man a:Chris ) a:Chris is a man.
DifferentIndividuals( a:Chris a:Stewie ) a:Chris and a:Stewie are different from each other.

The minimum cardinality expression MinCardinality( 2 a:fatherOf a:Man ) contains those individuals that are connected by a:fatherOf to at least two different instances of a:Man. Since a:Stewie and a:Chris are both instances of a:Man and are different from each other, a:Peter is classified as an instance of MinCardinality( 2 a:fatherOf a:Man ).

Due to open-world assumption, the last axiom — stating that a:Chris and a:Stewie are different from each other — is necessary for this inference: without this axiom, it is possible that a:Chris and a:Stewie are actually the same individual.

7.3.2 Maximum Cardinality

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

ObjectMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasPet a:Peter a:Brian ) a:Peter has a:Brian as a pet.
ClassAssertion( MaxCardinality( 1 a:hasPet ) a:Peter ) a:Peter has at most one pet.

The maximum cardinality expression MaxCardinality( 2 a:hasPet ) contains those individuals that are connected by a:hasPet to at most two individuals. Since a:Peter is known to be connected by a:hasPet to at most one individual, it certainly also connected by a:hasPet to at most two individuals so, consequently, a:Peter is classified as an instance of MaxCardinality( 2 a:hasPet ).

The example ontology explicitly names only a:Brian as being connected by a:hasPet from a:Peter, so one might expect a:Peter to be classified as an instance of MaxCardinality( 2 a:hasPet ) even without the second axiom. This, however, is not the case due to the open-world assumption. Without the last axiom, it is possible that a:Peter is connected by a:hasPet to other individuals. The second axiom closes the set of individuals that a:Peter is connected to by a:hasPet.

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasDaughter a:Peter a:Meg ) a:Meg is a daughter of a:Peter.
PropertyAssertion( a:hasDaughter a:Peter a:Megan ) a:Megan is a daughter of a:Peter.
ClassAssertion( MaxCardinality( 1 a:hasDaughter ) a:Peter ) a:Peter has at most one daughter.

One might intuitively expect this ontology to be inconsistent: on the one hand, it says that a:Meg and a:Megan are connected to a:Peter by a:hasDaughter, but, on the other hand, it says that a:Peter is connected by a:hasDaughter to at most one individual. However, this ontology is not inconsistent because OWL 2 does not apply the unique name assumption. The ontology does not explicitly say that a:Meg and a:Megan are different individuals; therefore, since a:Peter can be connected by a:hasDaughter to at most one different individual, one concludes that a:Meg is the same as a:Megan. This example ontology thus entails the assertion SameIndividual( a:Meg a:Megan ).

One can axiomatize the unique name assumption in OWL 2 by explicitly stating that all individuals are different from each other. This can be done by adding the following axiom, which makes the example ontology inconsistent.

DifferentIndividuals( a:Peter a:Meg a:Megan ) a:Peter, a:Meg, and a:Megan are all different from each other.

7.3.3 Exact Cardinality

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

IntersectionOf( MinCardinality( n OPE CE ) MinCardinality( n OPE CE ) ).

ObjectExactCardinality := 'ExactCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasPet a:Peter a:Brian ) a:Peter has a:Brian as a pet.
ClassAssertion( a:Dog a:Brian ) a:Brian is a dog.
ClassAssertion(
    AllValuesFrom( a:hasPet
       UnionOf(
          OneOf( a:Brian )
          ComplementOf( a:Dog )
        )
    )
    a:Peter
)
Each pet of a:Peter is either a:Brian or it is not a dog.

The exact cardinality expression ExactCardinality( 1 a:hasPet a:Dog ) contains those individuals that have hare connected by a:hasPet to exactly one instance of a:Dog. The example ontology says that a:Peter is connected toa:Brian by a:hasPet and that a:Brian is an instance of a:Dog; therefore, a:Peter is an instance of MinCardinality( 1 a:hasPet a:Dog ). Furthermore, the last axiom says that any individual different from a:Brian that is connected to a:Peter by a:hasPet is not an instance if a:Dog; therefore, a:Peter is an instance of MaxCardinality( 1 a:hasPet a:Dog ). Consequently, a:Peter is classified as an instance of ExactCardinality( 1 a:hasPet a:Dog ).

7.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 expression, the main difference being that the expressions for existential and universal quantification allow for several data property expressions and not just a single one. This allows for class expressions such as "objects whose width is greater than their height", where the values of width and height are specified using two data properties. 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 data values in the given data range. The DataAllValuesFrom class expression allows for a restricted universal quantification over a list of data property expression, and it contains those individuals that are connected through the data property expressions only to data values in the given data range. Finally, the DataHasValue class expression contains those individuals that are connected by a data property expression to a particular data value.


Restricting Data Property Expressions
Figure 10. Restricting Data Property Expressions

7.4.1 Existential Quantification

An existential class expression SomeValuesFrom( DPE1 ... DPEn DR ) consists of n data property expressions DPEi, 1 ≤ i ≤ n, and an n-ary data range DR, and contains all those individuals that are connected by DPEi to data values vi, 1 ≤ i ≤ n, such that the tuple < v1, ..., vn > is in DR.

DataSomeValuesFrom := 'SomeValuesFrom' '(' DataPropertyExpression { DataPropertyExpression } DataRange ')'

Consider the ontology consisting of the following axiom.

PropertyAssertion( a:hasAge a:Meg "17"^^xsd:integer ) a:Meg has age seventeen.

The existential class expression SomeValuesFrom( a:hasAge DatatypeRestriction( xsd:integer maxExclusive "20"^^xsd:integer ) ) contains all objects that are connected by a:hasAge to an integer strictly less than 20 so, consequently, a:Meg is classified as an instance of this expression.

7.4.2 Universal Quantification

A universal class expression AllValuesFrom( DPE1 ... DPEn DR ) consists of n data property expressions DPEi, 1 ≤ i ≤ n, and an n-ary data range DR, and contains all those individuals that are connected by DPEi only to data values vi, 1 ≤ i ≤ n, such that each tuple < v1, ..., vn > is in DR.

DataAllValuesFrom := 'AllValuesFrom' '(' DataPropertyExpression { DataPropertyExpression } DataRange ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:zipCode _:a1 "02903"^^xsd:integer ) The ZIP code of _:a1 is the integer 02903.
FunctionalProperty( a:hasZIP ) Each object can have at most one ZIP code.

In United Kingdom and Canada, ZIP codes are strings (i.e., they can contain characters and not just numbers). Hence, one might use the universal expression AllValuesFrom( a:hasZIP a:xsd:integer ) to identify those objects that have only integer ZIP codes (and therefore have non-UK and non-Canadian addresses). The anonymous individual _:a1 is by the first axiom connected by a:zipCode to an integer data value, and the second axiom ensures that _:a1 is not connected by a:zipCode to other data values; therefore, _:a1 is classified as an instance of AllValuesFrom( a:hasZIP a:xsd:integer ).

The last axiom — stating that a:hasZIP is functional — is critical for the inference from the previous paragraph due to the open-world assumption of OWL 2. Without this axiom, the ontology is incomplete in the sense that it may not list all individuals that _:a1 is conencted to by a:hasZIP; hence, without this axiom _:a1 would NOT be classified as an instance of AllValuesFrom( a:hasZIP a:xsd:integer ).

7.4.3 Restriction to a Constant

A has-value class expression HasValue( DPE C ) consists of a data property expression DPE and a constant C, and contains all those individuals that are connected by DPE to C. Each such expression is actually a syntactic abbreviation for the existential restriction

SomeValuesFrom( DPE OneOf( C ) ).

DataHasValue := 'HasValue' '(' DataPropertyExpression Constant ')'

Consider the ontology consisting of the following axiom.

PropertyAssertion( a:hasAge a:Meg "17"^^xsd:integer ) a:Meg is seventeen.

The has-value expression hasValue( a:hasAge "17"^^xsd:integer ) contains all individuals that are connected by a:hasAge to the integer 17 so, consequently, a:Meg is classified as an instance of this expression.

7.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, depending on whether there is a restriction on the data range that the connected data value must belong to. An unqualified cardinality restriction is equivalent to a qualified one where the restricting data range is rdfs:Literal. 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 data values in the specified data range, respectively.

Restricting the Cardinality of Data Property Expressions
Figure 11. Restricting the Cardinality of Data Property Expressions

7.5.1 Minimum Cardinality

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

DataMinCardinality := 'MinCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasName a:Meg "Meg" ) a:Meg is called "Meg".
PropertyAssertion( a:hasName a:Meg "Megan" ) a:Meg is called "Megan".

The minimum cardinality expression MinCardinality( 2 a:hasName ) contains those individuals that are connected by a:hasName to at least two different data values. Since "Meg" and "Megan" are different constants, the individual a:Meg is classified as an instance of this expression.

7.5.2 Maximum Cardinality

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

DataMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'

Consider the ontology consisting of the following axiom.

FunctionalProperty( a:hasName ) Each object can have at most one name.

The maximum cardinality expression MaxCardinality( 2 a:hasName ) contains those individuals that are connected by a:hasName to at most two different names. Since the ontology axiom restricts a:hasName to be functional, all individuals in the ontology are instances of this class expression.

7.5.3 Exact Cardinality

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

DataExactCardinality := 'ExactCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasName a:Brian "Brian" ) a:Brian is called "Brian".
FunctionalProperty( a:hasName ) Each object can have at most one name.

The exact cardinality expression ExactCardinality( 1 a:hasName ) contains those individuals that are connected by a:hasName to exactly one data value. Since the ontology axiom restricts a:hasName to be functional and a:Brian is connected by a:hasName to "Brian", it is classified as an instance of this expression.

8 Axioms

OWL 2 ontologies consist of axioms — statements that say what is true in the domain being modeled. OWL 2 provides an extensive set of axioms, which can be separated into axioms about class expressions, object property expressions, data property expressions, and assertions. All axiom types extend the Axiom class in the structural specification.

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

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

The Axioms of OWL 2
Figure 12. The Axioms of OWL 2

Axiom := Declaration | ClassAxiom | ObjectPropertyAxiom | DataPropertyAxiom | Assertion | EntityAnnotation | AnonymousIndividualAnnotation

8.1 Class Expressions Axioms

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

The Class Axioms of OWL 2
Figure 13. The Class Axioms of OWL 2

ClassAxiom := SubClassOf | EquivalentClasses | DisjointClasses | DisjointUnion

8.1.1 Subclass Axioms

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

subClassExpression := classExpression
superClassExpression := classExpression
SubClassOf := 'SubClassOf' '(' { Annotation } subClassExpression superClassExpression ')'

Consider the ontology consisting of the following axioms.

SubClassOf( a:Baby a:Child ) Each instance of a:Baby is an instance of a:Child.
SubClassOf( a:Child a:Person ) Each instance of a:Child is an instance of a:Person.
ClassAssertion( a:Baby a:Stewie ) a:Stewie is a baby.

Since a:Stewie is an instance of a:Baby, by the first subclass axiom a:Stewie is classified as an instance of a:Child as well. Similarly, by the second subclass axiom a:Stewie is classified as an instance of a:Person. This style of reasoning can be applied to any instance of a:Baby and not just a:Stewie; therefore, one can conclude that a:Baby is a subclass of a:Person. In other words, this ontology entails the subclass axiom SubClassOf( a:Baby a:Person ).

Consider the ontology consisting of the following axioms.

SubClassOf( a:PersonWithChild
    SomeValuesFrom( a:hasChild UnionOf( a:Boy a:Girl ) )
)
A person that has a child has either at least one boy or a girl.
SubClassOf( a:Boy a:Child ) Boys are children.
SubClassOf( a:Girl a:Child ) Girls are children.
SubClassOf( SomeValuesFrom( a:hasChild a:Child ) a:Parent ) If some object has a child, then this object is a parent.

The first axiom states that each instance of a:PersonWithChild is connected to an individual that is an instance of either a:Boy or a:Girl. (Because of the open-world assumption, this does not imply there must be only one such individual or that all such individuals must be instances of either a:Boy or of a:Girl.) Furthermore, each instance of a:Boy or a:Girl is an instance of a:Child. Finally, the last axiom says that all individuals that are connected by a:hasChild to an instance of a:Child are instances of a:Parent. Since this reasoning holds for each instance of a:PersonWithChild, each such instance is also an instance of a:Parent. In other words, this ontology entails the axiom SubClassOf( a:PersonWithChild a:Person ).

8.1.2 Equivalent Classes

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

SubClassOf( CE1 CE2 )
SubClassOf( CE2 CE1 )

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

EquivalentClasses := 'EquivalentClasses' '(' { Annotation } ClassExpression ClassExpression { ClassExpression } ')'

Consider the ontology consisting of the following axioms.

EquivalentClasses( a:Boy IntersectionOf( a:Child a:Man ) ) A boy is a male child.
ClassAssertion( a:Child a:Chris ) a:Chris is a child.
ClassAssertion( a:Man a:Chris ) a:Chris is a man.
ClassAssertion( a:Boy a:Stewie ) a:Stewie is a boy.

The first axiom defines the class a:Boy as an intersection of the classes a:Child and a:Man; thus, the instances of a:Boy are exactly those instances that are both an instance of a:Child and an instance of a:Man. Such a definition consists of two directions. The first direction implies that each instance of a:Child and a:Man is an instance of a:Boy; since a:Chris satisfies these two conditions, it is classified as an instance of a:Boy. The second direction implies that each a:Boy is an instance of a:Child and of a:Man; thus, a:Stewie is classified as an instance of a:Man and of a:Boy.

Consider the ontology consisting of the following axioms.

EquivalentClasses( a:MongrelOwner SomeValuesFrom( a:hasPet a:Mongrel ) ) A mongrel owner has a pet that is a mongrel.
EquivalentClasses( a:DogOwner SomeValuesFrom( a:hasPet a:Dog ) ) A dog owner has a pet that is a dog.
SubClassOf( a:Mongrel a:Dog ) A mongrel is a type of dog.
ClassAssertion( a:MongrelOwner a:Peter ) a:Peter is a mongrel owner.

By the first axiom, each instance x of a:MongrelOwner must be connected via a:hasPet to an instance of a:Mongrel; by the third axiom, this individual is an instance of a:Dog; thus, by the second axiom, x is an instance of a:DogOwner. In other words, this ontology entails the axiom SubClassOf( a:MongrelOwner a:DowOwner ). By the fourth axiom, a:Peter is then classified as an instance of a:DogOwner.

8.1.3 Disjoint Classes

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

DisjointClasses := 'DisjointClasses' '(' { Annotation } ClassExpression ClassExpression { ClassExpression } ')'

Consider the ontology consisting of the following axioms.

DisjointClasses( a:Boy a:Girl ) Nothing can be both a boy and a girl.
ClassAssertion( a:Boy a:Stewie ) a:Stewie is a boy.

The axioms in this ontology imply that a:Stewie can be classified as an instance of ComplementOf( a:Girl ). If the ontology were extended with the assertion ClassAssertion( a:Girl a:Stewie ), the ontology would become inconsistent.

8.1.4 Disjoint Union of Class Expression

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

EquivalentClasses( C UnionOf( CE1 ... CEn ) )
DisjointClasses( CE1 ... CEn )

DisjointUnion := 'DisjointUnion' '(' { Annotation } Class ClassExpression ClassExpression { ClassExpression } ')'

Consider the ontology consisting of the following axioms.

DisjointUnion( a:Child a:Boy a:Girl ) a:Child is a disjoint union of a:Boy and a:Girl.
ClassAssertion( a:Child a:Stewie ) a:Stewie is a child.
ClassAssertion( ComplementOf( a:Girl ) a:Stewie ) a:Stewie is not a girl.

By the first two axioms, a:Stewie is either an instance of a:Boy or a:Girl. The last assertion eliminates the second possibility, so a:Stewie is classified as an instance of a:Boy.

8.2 Object Property Axioms

Editor's Note: See Issue-22 (role-rule-sugar).

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

Object Property Axioms, Part I
Figure 14. Object Property Axioms, Part I

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.

Axioms Defining Characteristics of Object Properties, Part II
Figure 15. Axioms Defining Characteristics of Object Properties, Part II

ObjectPropertyAxiom :=
    SubObjectPropertyOf | EquivalentObjectProperties |
    DisjointObjectProperties | InverseObjectProperties |
    ObjectPropertyDomain | ObjectPropertyRange |
    FunctionalObjectProperty | InverseFunctionalObjectProperty |
    ReflexiveObjectProperty | IrreflexiveObjectProperty |
    SymmetricObjectProperty | AsymmetricObjectProperty |
    TransitiveObjectProperty

8.2.1 Object Subproperties

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

The basic form is SubPropertyOf( OPE1 OPE2 ), and this axiom states that the object property expression OPE1 is a subproperty of the object property expression OPE2 — that is, if an individual x is connected by OPE1 to an individual y, then x is also connected by OPE2 to y.

The more complex form is SubPropertyOf( PropertyChain( OPE1 ... OPEn ) OPE ), and this axiom states, if an individual x is connected by a sequence of object property expressions OPE1, ..., OPEn 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].

propertyExpressionChain := 'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
subObjectPropertyExpression := ObjectPropertyExpression | propertyExpressionChain
SubObjectPropertyOf := 'SubPropertyOf' '(' { Annotation } SubObjectPropertyExpression ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

SubPropertyOf( a:hasDog a:hasPet ) Having a dog is a kind of having a pet.
PropertyAssertion( a:hasDog a:Peter a:Brian ) a:Peter has a:Brian as a dog.

Since a:hasDog is a subproperty of a:hasPet, each tuple of individuals connected by the former property expression is also connected by the latter property expression. Therefore, this ontology entails that a:Peter is connected to a:Brian by a:hasPet; that is, the ontology entails the assertion PropertyAssertion( a:hasPet a:Peter a:Brian ).

Consider the ontology consisting of the following axioms.

SubPropertyOf( PropertyChain( a:hasMother a:hasSister ) a:hasAunt ) If x is connected by a:hasMother with y, and y is connected by a:hasSister with z, then x is connected by a:hasAunt with z; that is, an aunt z of x is a sister x's mother.
PropertyAssertion( a:hasMother a:Stewie a:Lois ) a:Lois is the mother of a:Stewie.
PropertyAssertion( a:hasSister a:Lois a:Carol ) a:Carol is a sister of a:Lois.

The axioms in this ontology imply that a:Stewie is connected by a:hasAunt with a:Carol; that is, the ontology entails the assertion PropertyAssertion( a:hasAunt a:Stewie a:Carol ).

8.2.2 Equivalent Object Properties

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

SubPropertyOf( OPE1 OPE2 )
SubPropertyOf( OPE2 OPE1 )

EquivalentObjectProperties := 'EquivalentProperties' '(' { Annotation } ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'

Consider the ontology consisting of the following axioms.

EquivalentProperties( a:hasBrother a:hasMaleSibling ) a:hasBrother and a:hasMaleSibling are synonyms.
PropertyAssertion( a:hasBrother a:Chris a:Stewie ) a:Chris has a brother a:Stewie.
PropertyAssertion( a:hasMaleSibling a:Stewie a:Chris ) a:Stewie has male sibling a:Chris.

Since a:hasBrother and a:hasMaleSibling are equivalent properties, this ontology entails that a:Chris is connected by a:hasMaleSiblig with a:Stewie — that is, the ontology entails the assertion PropertyAssertion( a:hasMaleSibling a:Chris a:Stewie )) — and that a:Stewie is connected by a:hasBrother with a:Chris — that is, the ontology entails the assertion PropertyAssertion( a:hasBrother a:Stewie a:Chris ).

8.2.3 Disjoint Object Properties

A disjoint object properties axiom DisjointProperties( OPE1 ... OPEn ) states that all of the object property expressions OPEi, 1 ≤ i ≤ n, are mutually disjoint with each other; that is, no pair of individuals < x, y > can at the same time be connected by both OPEi and OPEj for i ≠ j.

DisjointObjectProperties := 'DisjointProperties' '(' { Annotation } ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'

Consider the ontology consisting of the following axioms.

DisjointProperties( a:hasFather a:hasMother ) Fatherhood is disjoint with motherhood.
PropertyAssertion( a:hasFather a:Stewie a:Peter ) a:Peter is the father of a:Stewie.
PropertyAssertion( a:hasMother a:Stewie a:Lois ) a:Lois is the mother of a:Stewie.

In this ontology, the disjointness axiom is satisfied. If, however, one were to add an assertion PropertyAssertion( a:hasMother a:Stewie a:Peter ), the disjointness axiom would be invalidated and the ontology would become inconsistent.

8.2.4 Object Property Domain

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

SubClassOf( SomeValuesFrom( OPE owl:Thing ) CE )

ObjectPropertyDomain := 'PropertyDomain' '(' { Annotation } ObjectPropertyExpression ClassExpression ')'

Consider the ontology consisting of the following axioms.

PropertyDomain( a:hasDog a:Person ) The domain of a:hasDog is a:Person.
PropertyAssertion( a:hasDog a:Peter a:Brian ) a:Peter has a:Brian as a dog.

By the first axiom, each individual that has an outgoing a:hasDog connection must be an instance of a:Person. Therefore, a:Peter can be classified as an instance of a:Person; that is, this ontology entails the assertion ClassMember( a:Peter a:Person ).

Domain axioms in OWL 2 have a standard first-order semantics that is somewhat different from the semantics of such axioms in databases and object-oriented systems, where such axioms are interpreted as checks. The domain axiom from the example ontology would in such systems be interpreted as a constraint saying that a:hasDog can point only from individuals that are known to be instances of a:Person; furthermore, since the example ontology does not explicitly state that a:Peter is an instance of a:Person, one might expect the domain constraint to be invalidated.

8.2.5 Object Property Range

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

SubClassOf( owl:Thing AllValuesFrom( OPE CE ) )

ObjectPropertyRange := 'PropertyRange' '(' { Annotation } ObjectPropertyExpression ClassExpression ')'

Consider the ontology consisting of the following axioms.

PropertyRange( a:hasDog a:Dog ) The range of a:hasDog is a:Dog.
PropertyAssertion( a:hasDog a:Peter a:Brian ) a:Peter has a:Brian as a dog.

By the first axiom, each individual that has an incoming a:hasDog connection must be an instance of a:Dog. Therefore, a:Brian can be classified as an instance of a:Dog; that is, this ontology entails the assertion ClassMember( a:Brian a:Dig ).

Range axioms in OWL 2 have a standard first-order semantics that is somewhat different from the semantics of such axioms in databases and object-oriented systems, where such axioms are interpreted as checks. The range axiom from the example ontology would in such systems be interpreted as a constraint saying that a:hasDog can point only to individuals that are known to be instances of a:Dog; furthermore, since the example ontology does not explicitly state that a:Brian is an instance of a:Dog, one might expect the range constraint to be invalidated.

8.2.6 Inverse Object Properties

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

EquivalentProperties( OPE1 InverseOf( OPE2 ) )

InverseObjectProperties := 'InverseProperties' '(' { Annotation } ObjectPropertyExpression ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

InverseProperties( a:hasFather a:fatherOf ) The object properties a:hasFather and a:fatherOf are inverse to each other.
PropertyAssertion( a:hasFather a:Stewie a:Peter ) a:Stewie has father a:Peter.
PropertyAssertion( a:fatherOf a:Peter a:Chris ) a:Peter is the father of a:Chris.

This ontology entails that a:Peter is connected by a:fatherOf with a:Stewie — that is, the ontology entails the assertion PropertyAssertion( a:fatherOf a:Peter a:Stewie ) — and it also entails that a:Chris is connected by a:hasFather with a:Peter — that is, the ontology entails the assertion PropertyAssertion( a:hasFather a:Chris a:Peter ).

8.2.7 Functional Object Properties

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

SubClassOf( owl:Thing MaxCardinality( 1 OPE ) )

FunctionalObjectProperty := 'FunctionalProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

FunctionalProperty( a:hasFather ) Each person can have at most one father.
PropertyAssertion( a:hasFather a:Stewie a:Peter ) a:Stewie has father a:Peter.
PropertyAssertion( a:hasFather a:Stewie a:Peter_Griffin ) a:Stewie has father a:Peter_Griffin.

By the first axiom, a:hasFather can point from a:Stewie to at most one distinct individual, so a:Peter and a:Peter_Griffin must be equal; that is, this ontology entails the assertion SameIdnvididual( a:Peter a:Peter_Griffin ).

One might intuitively expect the previous ontology to be inconsistent, since the a:hasFather property points to two different values for a:Stewie. By default, however, OWL 2 does not assume the unique name assumption, so a:Peter and a:Peter_Griffin are not necessarily distinct individuals. If the ontology were extended with the axiom DifferentIndividuals( a:Peter a:Peter_Griffin ), then it would indeed become inconsistent.

8.2.8 Inverse-Functional Object Properties

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

SubClassOf( owl:Thing MaxCardinality( 1 InverseOf( OPE ) ) )

InverseFunctionalObjectProperty := 'InverseFunctionalProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

InverseFunctionalProperty( a:fatherOf ) Each person can have at most one father.
PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:Peter is the father of a:Stewie.
PropertyAssertion( a:fatherOf a:Peter_Griffin a:Stewie ) a:Peter_Griffin is the father of a:Stewie.

By the first axiom, at most one distinct individual can point by a:fatherOf to a:Stewie, so a:Peter and a:Peter_Griffin must be equal; that is, this ontology entails the assertion SameIndividual( a:Peter a:Peter_Griffin ).

One might intuitively expect the previous ontology to be inconsistent, since there are two individuals that a:Stewie is connected to by a:fatherOf. By default, however, OWL 2 does not assume the unique name assumption, so a:Peter and a:Peter_Griffin are not necessarily distinct individuals. If the ontology were extended with the axiom DifferentIndividuals( a:Peter a:Peter_Griffin ), then it would indeed become inconsistent.

8.2.9 Reflexive Object Properties

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

ReflexiveObjectProperty := 'ReflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

ReflexiveProperty( a:knowns ) Everybody knows themselves.
ClassAssertion( a:Person a:Peter ) a:Peter is a person.

By the first axiom, a:Peter must be connected by a:knows to itself; that is, this ontology entails the assertion PropertyAssertion( a:knows a:Peter a:Peter ).

8.2.10 Irreflexive Object Properties

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

IrreflexiveObjectProperty := 'IrreflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

IrreflexiveProperty( a:marriedTo ) Nobody can be married to himself.

If this ontology were extended with the assertion PropertyAssertion( a:marriedTo a:Peter a:Peter ), the irreflexivity axiom would be contradicted and the ontology would become inconsistent.

8.2.11 Symmetric Object Properties

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

SubPropertyOf( OPE InverseOf( OPE ) ).

SymmetricObjectProperty := 'SymmetricProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

SymmetricProperty( a:friend ) The property a:friend is symmetric.
PropertyAssertion( a:friend a:Peter a:Brian ) a:Brian is a friend of a:Peter.

Since a:friend is symmetric, a:Peter must be connected by a:friend to a:Brian; that is, this ontology entails the assertion PropertyAssertion( a:friend a:Brian a:Peter ).

8.2.12 Asymmetric Object Properties

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

AsymmetricObjectProperty := 'AsymmetricProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

AsymmetricProperty( a:parentOf ) The property a:parentOf is asymmetric.
PropertyAssertion( a:parentOf a:Peter a:Stewie ) a:Peter is a parent of a:Stewie.

If this ontology were extended with the assertion PropertyAssertion( a:parentOf a:Stewie a:Peter ), the asymmetry axiom would be invalidated and the ontology would become inconsistent.

8.2.13 Transitive Object Properties

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

SubPropertyOf( PropertyChain( OPE OPE ) OPE ).

TransitiveObjectProperty := 'TransitiveProperty' '(' { Annotation } ObjectPropertyExpression ')'

Consider the ontology consisting of the following axioms.

TransitiveProperty( a:ancestorOf ) The property a:ancestorOf is transitive.
PropertyAssertion( a:ancestorOf a:Carter a:Lois ) a:Carter is an ancestor of a:Lois.
PropertyAssertion( a:ancestorOf a:Lois a:Meg ) a:Lois is an ancestor of a:Meg.

Since a:ancestorOf is transitive, a:Carter must be connected by a:ancestorOf to a:Meg; that is, this ontology entails the assertion PropertyAssertion( a:ancestorOf a:Carter a:Meg ).

8.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–data value pairs. The DataPropertyDomain and DataPropertyRange axioms can be used to restrict the first and the second individual, respectively, connected by a data property expression to be instances of the specified class expression and data range, respectively. 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.

Data Property Axioms of OWL 2
Figure 16. Data Property Axioms of OWL 2

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

DataPropertyAxiom :=
    SubDataPropertyOf | EquivalentDataProperties | DisjointDataProperties |
    DataPropertyDomain | DataPropertyRange | FunctionalDataProperty

8.3.1 Data Subproperties

A data subproperty axiom SubPropertyOf( DPE1 DPE2 ) states that the data property expression DPE1 is a subproperty of the data property expression DPE2 — that is, if an individual x is connected by OPE1 to a data value y, then x is also connected by OPE2 to y.

SubDataPropertyOf := 'SubPropertyOf' '(' { Annotation } DataPropertyExpression DataPropertyExpression ')'

Consider the ontology consisting of the following axioms.

SubPropertyOf( a:hasFirstName a:hasName ) Having a first name is a kind of having a name.
PropertyAssertion( a:hasFirstName a:Peter "Peter" ) a:Peter has first name "Peter".

Since a:hasFirstName is a subproperty of a:hasName, each individual connected by the former property to some value is also connected by the latter property to this value. Therefore, this ontology entails that a:Peter is connected to "Peter" by a:hasName; that is, the ontology entails the assertion PropertyAssertion( a:hasName a:Peter "Peter" ).

8.3.2 Equivalent Data Properties

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

SubPropertyOf( DPE1 DPE2 )
SubPropertyOf( DPE2 DPE1 )

EquivalentDataProperties := 'EquivalentProperties' '(' { Annotation } DataPropertyExpression DataPropertyExpression { DataPropertyExpression } ')'

Consider the ontology consisting of the following axioms.

EquivalentProperties( a:hasName a:seLlama ) a:hasBrother and a:seLlama (in Spanish) are synonyms.
PropertyAssertion( a:hasName a:Chris "Chris" ) a:Chris has name "Chris".
PropertyAssertion( a:seLlama a:Chris "Chris Griffin" ) a:Chris has name "Chris Griffin".

Since a:hasName and a:seLlama are equivalent properties, this ontology entails that a:Chris is connected by a:seLlama with "Chris" — that is, the ontology entails the assertion PropertyAssertion( a:seLlama a:Chris "Chris" )) — and that a:Chris is also connected by a:hasName with "Chris Griffin" — that is, the ontology entails the assertion PropertyAssertion( a:hasName a:Chris "Chris Griffin" ).

8.3.3 Disjoint Data Properties

A disjoint data properties axiom DisjointProperties( DPE1 ... DPEn ) states that all of the data property expressions DPEi, 1 ≤ i ≤ n, are mutually disjoint with each other; that is, no individual-data value pair < x, y > can be at the same time be connected with both DPEi and DPEj for i ≠ j.

DisjointDataProperties := 'DisjointProperties' '(' { Annotation } DataPropertyExpression DataPropertyExpression { DataPropertyExpression } ')'

Consider the ontology consisting of the following axioms.

DisjointProperties( a:hasName a:hasAddress ) The values for a name are different from the values for an address.
PropertyAssertion( a:hasName a:Peter "Peter" ) a:Peter has name "Peter".
PropertyAssertion( a:hasAddress a:Peter "Quahog, Rhode Island" ) a:Peter has address "Quahog, Rhode Island".

In this ontology, the disjointness axiom is satisfied. If, however, one were to add an assertion PropertyAssertion( a:hasAddress a:Peter "Peter" ), the disjointness axiom would be invalidated and the ontology would become inconsistent.

8.3.4 Data Property Domain

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

SubClassOf( SomeValuesFrom( DPE rdfs:Literal) CE )

DataPropertyDomain := 'PropertyDomain' '(' { Annotation } DataPropertyExpression ClassExpression ')'

Consider the ontology consisting of the following axioms.

PropertyDomain( a:hasName a:Person ) The domain of a:hasName is a:Person.
PropertyAssertion( a:hasName a:Peter "Peter" ) a:Peter has name "Peter".

By the first axiom, each individual that has an outgoing a:hasName connection must be an instance of a:Person. Therefore, a:Peter can be classified as an instance of a:Person; that is, this ontology entails the assertion ClassMember( a:Peter a:Person ).

Domain axioms in OWL 2 have a standard first-order semantics that is somewhat different from the semantics of such axioms in databases and object-oriented systems, where such axioms are interpreted as checks. Thus, the domain axiom from the example ontology would in such systems be interpreted as a constraint saying that a:hasName can point only from individuals that are known to be instances of a:Person; furthermore, since the example ontology does not explicitly state that a:Peter is an instance of a:Person, one might expect the domain constraint to be invalidated.

8.3.5 Data Property Range

A data property range axiom PropertyRange( DPE DR ) states that the range of the data property expression DPE is the data range DR — that is, if some individual is connected by DPE with a data value x, then x is contained in DR. This axiom can be seen as equivalent to the following axiom:

SubClassOf( owl:Thing AllValuesFrom( DPE DR ) )

DataPropertyRange := 'PropertyRange' '(' { Annotation } DataPropertyExpression DataRange ')'

Consider the ontology consisting of the following axioms.

PropertyRange( a:hasName xsd:string ) The range of a:hasDog is a:Dog.
PropertyAssertion( a:hasName a:Peter "Peter" ) a:Peter has name "Peter".

By the first axiom, each data value that has an incoming a:hasName link must be in xsd:string. In the example ontology, this axiom is satisfied. If, however, the ontology were extended with an assertion PropertyAssertion( a:hasName a:Peter 42^^xsd:integer ), the range axiom would imply that 42^^xsd:integer is in xsd:string, which is a contradiction; therefore, the ontology would become inconsistent.

8.3.6 Functional Data Properties

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

SubClassOf( owl:Thing MaxCardinality( 1 DPE ) )

FunctionalDataProperty := 'FunctionalProperty' '(' { Annotation } DataPropertyExpression ')'

Consider the ontology consisting of the following axioms.

FunctionalProperty( a:hasAge ) Each person can have at most one age.
PropertyAssertion( a:hasAge a:Meg 17^^xsd:integer ) a:Meg is 17 years old.

By the first axiom, a:hasAge can point from a:Meg to at most one distinct data value. In this example ontology, this axiom is satisfies. If, however, the ontology were extended with the assertion PropertyAssertion( a:hasAge a:Meg 15^^xsd:integer ), the semantics of functionality axioms would imply that 15^^xsd:integer is equal to 17^^xsd:integer, which is a contradiction; therefore, the ontology would become inconsistent.

8.4 Assertions

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

Class and Individual (In)Equality Assertions
Figure 17. Class and Individual (In)Equality Assertions

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

Object Property Assertions
Figure 18. Object Property Assertions

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

Data Property Assertions
Figure 19. Data Property Assertions

Assertion := SameIndividual | DifferentIndividuals | ClassAssertion |
    ObjectPropertyAssertion | NegativeObjectPropertyAssertion |
    DataPropertyAssertion | NegativeDataPropertyAssertion

sourceIndividual := Individual
targetIndividual := Individual
targetValue := Constant

8.4.1 Individual Equality

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

SameIndividual := 'SameIndividual' '(' { Annotation } Individual Individual { Individual } ')'

Consider the ontology consisting of the following axioms.

SameIndividual( a:Meg a:Megan ) a:Meg and a:Megan are synonyms.
PropertyAssertion( a:hasBrother a:Meg a:Stewie ) a:Meg has a brother a:Stewie.

Since a:Meg and a:Megan are synonyms, one individual can always be replaced with the other one. Therefore, this ontology entails that a:Megan is connected by a:hasBrother with a:Stewie — that is, the ontology entails the assertion PropertyAssertion( a:hasBrother a:Megan a:Stewie )).

8.4.2 Individual Inequality

An individual inequality axiom DifferentIndividuals( I1 ... In ) states that all of the individuals Ii, 1 ≤ i ≤ n, are mutually different from each other; that is, no individuals Ii and Ij with i ≠ j can be derived to be equal. This axiom can be used to axiomatize the unique name assumption — the assumption that all syntactically different individuals are different from each other.

DifferentIndividuals := 'DifferentIndividuals' '(' { Annotation } Individual Individual { Individual } ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:fatherOf a:Peter a:Meg ) a:Peter is a father of a:Meg.
PropertyAssertion( a:fatherOf a:Peter a:Chris ) a:Peter is a father of a:Chris.
PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:Peter is a father of a:Stewie.
DifferentIndividuals( a:Peter a:Meg a:Chris a:Stewie ) All of these individuals are different from each other.

The last axiom in this example ontology axiomatizes the unique name assumption. Therefore, if the ontology were extended with an axiom FunctionalProperty( a:fatherOf ), this axiom would imply that a:Meg, a:Chris, and a:Stewie are all equal, which would invalidate the unique name assumption and would make the ontology inconsistent.

8.4.3 Class Assertions

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

ClassAssertion := 'ClassAssertion' '(' { Annotation } ClassExpression Individual ')'

Consider the ontology consisting of the following axioms.

ClassAssertion( a:Dog a:Brian ) a:Brian is a a:Dog.
SubClassOf( a:Dog a:Mammal ) Dogs are mammals.

The first axiom states that a:Brian is an instance of the class a:Dog. By the second axioms, each instance of a:Dog is an instance of a:Mammal. Therefore, this ontology entails that a:Brian is an instance of a:Mammal — that is, the ontology entails the assertion ClassAssertion( a:Mammal a:Brian ).

8.4.4 Positive Object Property Assertions

A positive object property assertion PropertyAssertion( OPE I1 I2 ) states that the individual I1 is connected by the object property expression OPE to the individual I2.

ObjectPropertyAssertion := 'PropertyAssertion' '(' { Annotation } ObjectPropertyExpression sourceIndividual targetIndividual ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasDog a:Peter a:Brian ) a:Peter has dog a:Brian.
SubClassOf( SomeValuesFrom( a:hasDog owl:Thing ) a:DogOwner ) Things having a dog are dog owners.

The first axiom states that a:Peter is connected by a:hasDog to a:Brian. By the second axioms, each individual connected by a:hasDog to an individual is an instance of a:DogOwner. Therefore, this ontology entails that a:Peter is an instance of a:DogOwner — that is, the ontology entails the assertion ClassAssertion( a:DogOwner a:Peter ).

8.4.5 Negative Object Property Assertions

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

NegativeObjectPropertyAssertion := 'NegativePropertyAssertion' '(' { Annotation } objectPropertyExpression sourceIndividual targetIndividual ')'

Consider the ontology consisting of the following axiom.

NegativePropertyAssertion( a:hasSon a:Peter a:Meg ) a:Meg is not a son of a:Peter.

If this ontology were extended with an assertion PropertyAssertion( a:hasSon a:Peter a:Meg ), the negative object property assertion would be invalidated and the ontology would become inconsistent.

8.4.6 Positive Data Property Assertions

A positive data property assertion PropertyAssertion( DPE I C ) states that the individual I is connected by the data property expression DPE to the constant C.

DataPropertyAssertion := 'PropertyAssertion' '(' { Annotation } DataPropertyExpression sourceIndividual targetValue ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasAge a:Meg 17^^xsd:integer ) a:Meg is 17 years old.
SubClassOf(
    SomeValuesFrom( a:hasAge
       DatatypeRestriction( xsd:integer
          minInclusive 13^^xsd:integer
          maxInclusive 19^^xsd:integer
       )
    )
    a:Teenager
)
Teenagers are older than 13 and younger than 19 (both inclusive).

The first axiom states that a:Meg is connected by a:hasAge to 17^^xsd:integer. By the second axioms, each individual connected by a:hasAge to a data value between 13 and 19 is an instance of a:Teenager. Therefore, this ontology entails that a:Meg is an instance of a:Teenager — that is, the ontology entails the assertion ClassAssertion( a:Teenager a:Meg ).

8.4.7 Negative Data Property Assertions

A negative data property assertion NegativePropertyAssertion( DPE I C ) states that the individual I is not connected by the data property expression DPE to the constant C.

NegativeDataPropertyAssertion := 'NegativePropertyAssertion' '(' { Annotation } DataPropertyExpression sourceIndividual targetValue ')'

Consider the ontology consisting of the following axiom.

NegativePropertyAssertion( a:hasAge a:Meg 5^^xsd:integer ) a:Meg is not five years old.

If this ontology were extended with an assertion PropertyAssertion( a:hasAge a:Meg 5^^xsd:integer ), the negative data property assertion would be invalidated and the ontology would become inconsistent.

9 Annotations

OWL 2 applications often need ways to associate information with ontologies, entities, and axioms in a way that does not affect the logical meaning of the ontology. For example, one might want to associate human-readable labels with entities and use them when visualizing an ontology. Such information often plays a central role in OWL 2 applications. Although such information should not affect the formal meaning of an ontology (i.e., it should not affect the set of consequences that one can derive from an ontology), it should be accessible in the structural specification of OWL 2. To this end, OWL 2 provides for annotations on ontologies, axioms, and entities.

Different OWL 2 syntaxes may provide a mechanism for embedding comments into ontology documents; for example, the OWL 2 XML Syntax [OWL 2 XML Syntax] provides for the standard XML commenting mechanism. The structure of such comments, however, is dependent on the syntax, so representing this structure at the level of the structural specification may be difficult and/or impossible. Thus, such comments are not represented in the structural specification of OWL 2 and are simply discarded during parsing. In contrast, annotations are "first-class citizens" in the structural specification of OWL 2, and their structure is independent of the underlying syntax.

9.1 Annotation Values

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

  • Annotation values can be constants. Note that these need not be just strings; rather, any OWL 2 constant can be used. For example, one can create an annotation whose value is a URI formatted according to the XML Schema xsd:anyURI type specification.
  • Annotation values can be ontology entities. Such annotations make it clearer that the value is not just some constant, but an entity from this or some other ontology.
  • Annotation values can be anonymous individuals.


Annotations in OWL 2
Figure 20. Annotations in OWL 2

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

explicitAnnotationByConstant := 'Annotation' '(' AnnotationProperty Constant ')'
labelAnnotation := 'Label' '(' Constant ')'
commentAnnotation := 'Comment' '(' Constant ')'
deprecationAnnotation := 'Deprecated'
AnnotationByConstant := explicitAnnotationByConstant | labelAnnotation | commentAnnotation | deprecationAnnotation
AnnotationByEntity := 'Annotation' '(' AnnotationProperty Entity ')'
AnnotationByAnonymousIndividual := 'Annotation' '(' AnnotationProperty AnonymousIndividual ')'
Annotation := AnnotationByConstant | AnnotationByEntity | AnnotationByAnonymousIndividual

9.2 Annotations of Axioms and Ontologies

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

The following axiom contains a comment that explains the purpose of the axiom.

SubClassOf( Comment("Male people are people.") a:Man a:Person)

Since annotations affect structural equivalence between axioms, the previous axiom is NOT structurally equivalent with the following axiom, even though these two axioms are equivalent according to the semantics of OWL 2.

SubClassOf( a:Man a:Person)

9.3 Annotations of Entities and Anonymous Individuals

Editor's Note: See Issue-16 (entity annotations).

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

Annotations of Entities and Anonymous Individuals in OWL 2
Figure 21. Annotations of Entities and Anonymous Individuals in OWL 2

axiomAnnotations := Annotation { Annotation }
targetAnnotations := Annotation { Annotation }
EntityAnnotation := 'EntityAnnotation' '(' axiomAnnotations Entity targetAnnotations ')'
AnonymousIndividualAnnotation := 'AnonymousIndividualAnnotation' '(' axiomAnnotations AnonymousIndividual targetAnnotations ')'

The following axiom assigns a human-readable comment to the class a:Person.

EntityAnnotation( Class( a:Person ) Comment( "Represents all people in the domain." ) )

10 Global Restrictions on Axioms

As explained in the literature [SROIQ], to obtain a decidable language the axiom closure Ax of each OWL 2 ontology must obey certain global restrictions, as defined next.

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

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

An object property expression PE is composite in Ax if Ax contains an axiom of the form

  • SubPropertyOf( PropertyChain( PE1 ... PEn ) PE ) with n > 1, or
  • SubPropertyOf( PropertyChain( PE1 ... PEn ) INV(PE) ) with n > 1, or
  • TransitiveProperty( PE ), or
  • TransitiveProperty( INV(PE) ).

The hierarchy relation → is the smallest relation on object property expressions for which the following conditions hold (AB means that → holds for A and B):

  • if Ax contains an axiom SubPropertyOf( PE1 PE2 ), then PE1PE2 holds; and
  • if Ax contains an axiom EquivalentProperties( PE1 PE2 ), then PE1PE2 and PE2PE1 hold; and
  • if Ax contains an axiom InverseProperties( PE1 PE2 ), then PE1INV(PE2) and INV(PE2)PE1 hold; and
  • if Ax contains an axiom SymmetricProperty(PE), then PEINV(PE) holds; and
  • if PE1PE2 holds, then INV(PE1)INV(PE2) holds as well.

The relation →* is the reflexive-transitive closure of →. An object property expression PE is simple in Ax if, for each object property expression PE' such that PE'* PE holds, PE' is not composite.

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

  • Each class in Ax of the following form contains only simple object property expressuibs:
    • MinCardinality, MaxCardinality, ExactCardinality, and ExistsSelf.
  • Each axiom in Ax of the following form contains only simple object property expressions:
    • FunctionalProperty, InverseFunctionalProperty, IrreflexiveProperty, AsymmetricProperty, and DisjointProperties.
  • A strict partial order < on the object property expressions must exist that fulfills the following conditions:
    • If x < y holds, then y →* x does not hold;
    • Each axiom in Ax of the form SubPropertyOf( SUB PE ) where SUB is of the form PropertyChain( PE1 ... PEn ) with n ≥ 2 fulfills the following conditions:
      • n = 2 and PE1 = PE2 = PE, or
      • PEi < PE for each 1 ≤ i ≤ n, or
      • PE1 = PE and PEi < PE for each 2 ≤ i ≤ n, or
      • PEn = PE and PEi < PE for each 1 ≤ i ≤ n-1.

11 Appendix: Differences from OWL 1 Abstract Syntax

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

11.1 Dropping the Frame-Like Syntax

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

The following is an example of a frame-like axiom.

ObjectProperty( a:partOf inverseOf( a:containedIn ) inverseFunctional transitive     Label("Specifies that an object is a part of another object.") )

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

The OWL 1 axiom from the previous example can be represented in OWL 2 using the following axioms.

Declaration( ObjectProperty( a:partOf ) )
EntityAnnotation( ObjectProperty( a:partOf ) Label("Specifies that an object is a part of another object.") )
InverseProperties( a:partOf a:containedIn )
InverseFunctionalProperty( a:partOf )
TransitiveProperty( a:partOf )

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

11.2 Inverse Property Expressions

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

In OWL 1, one can state the following axiom to axiomatize a:hasPart as the inverse property of a:isPartOf.

ObjectProperty( a:hasPart inverse a:isPartOf )

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

The following OWL 2 axiom asserts that a:isPartOf is the inverse of a:hasPart, and is thus semantically equivalent to the OWL 1 axiom from the previous example.

EquivalentProperties( a:hasPart InverseOf( a:isPartOf ) )

Such axioms are quite common, so OWL 2 provides the following syntactic shortcut as well.

InverseProperties( a:hasPart a:isPartOf )

12 Complete Grammar (Normative)

Editor's Note: The complete grammar will be reproduced here once the specification has been completed.
Editor's Note: To make this section normative and complete will require listing all built-in classes and datatypes and defining axiom closure here.

13 Index

Editor's Note: The index will be created once the specification has been completed.

14 References

[OWL 2 Semantics]
OWL 2 Web Ontology Language: Model-Theoretic Semantics. Bernardo Cuenca Grau and Boris Motik, eds., 2008.
[OWL 2 XML Syntax]
OWL 2 Web Ontology Language: XML Serialization. Bernardo Cuenca Grau, Boris Motik, and Peter. F. Patel-Schneider, eds., 2008.
[SROIQ]
The Even More Irresistible SROIQ. Ian Horrocks, Oliver Kutz, and Uli Sattler. In Proc. of the 10th Int. Conf. on Principles of Knowledge Representation and Reasoning (KR 2006). AAAI Press, 2006.
[XML Namespaces]
Namespaces in XML 1.0 (Second Edition). Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin, eds. W3C Recommendation 16 August 2006.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, eds. W3C Recommendation 28 October 2004.
[RDF Syntax]
RDF/XML Syntax Specification (Revised). Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/rdf-syntax-grammar/.
[RFC-4646]
RFC 4646 - Tags for Identifying Languages. M. Phillips and A. Davis. IETF, September 2006, http://www.ietf.org/rfc/rfc4646.txt. Latest version is available as BCP 47, (details) .
[RFC-3987]
RFC 3987 - Internationalized Resource Identifiers (IRIs). M. Duerst, M. Suignard. IETF, January 2005, http://www.ietf.org/rfc/rfc3987.txt.
[OWL Semantics and Abstract Syntax]
OWL Web Ontology Language: Semantics and Abstract Syntax Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, eds. W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/. Latest version available at http://www.w3.org/TR/owl-semantics/.
[CURIE]
CURIE Syntax 1.0: A syntax for expressing Compact URIs. M. Birbeck, S. McCarron, Editors, W3C Working Draft, 26 November 2007, http://www.w3.org/TR/2007/WD-curie-20071126/.
[RDF Test Cases]
RDF Test Cases. Jan Grant and Dave Beckett, Editors, W3C Recommendation 10 February 2004, http://www.w3.org/TR/rdf-testcases/.
[UNICODE]
The Unicode Standard, Version 5.1.0. The Unicode Consortium.