W3C


OWL 2 Web Ontology Language:Structural Specification and Functional-Style Syntax

W3C Editor's Draft 08 October21 November 2008

This version:
http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081008/http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081121/
Latest editor's draft:
http://www.w3.org/2007/OWL/draft/owl2-syntax/
Previous version:
http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081007/http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081008/ (color-coded diff)
Editors:
Boris Motik, Oxford University
Peter F. Patel-Schneider, Bell Labs Research, Alcatel-Lucent
Bijan Parsia, University of Manchester
Contributors:
Ian Horrocks, Oxford University
Note: The complete list of contributors is being compiled and will be included in the next draft.

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

Abstract

OWL 2 extends the W3C OWL Web Ontology Language with a small but useful set of features that have been requested by users, for which effective reasoning algorithms are now available, and that OWL tool developers are willing to support. The new features include extra syntactic sugar, additional property and qualified cardinality constructors, extended datatype support, simple metamodelling,metamodeling, and extended annotations.
This document defines 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

May Be Superseded

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

This document is being published as one of a set of 711 documents:

  1. Structural Specification and Functional-Style Syntax (this document)
  2. Direct Semantics
  3. RDF-Based Semantics
  4. Conformance and Test Cases
  5. Mapping to RDF Graphs
  6. XML Serialization
  7. Profiles
  8. Conformance and Test Cases Compatibility with OWL 1Quick Reference Guide
  9. New Features & Rationale
  10. Manchester Syntax
  11. rdf:text: A Datatype for Internationalized Text

Please Comment By 2008-11-25

The OWL Working Group intendsseeks public feedback on these Working Drafts. Please send your comments to make OWL 2 be a supersetpublic-owl-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of OWL 1, exceptthis document for internal-review comments and changes being drafted which may address your concerns.

No Endorsement

Publication as a limited number of situations where we believeWorking Draft does not imply endorsement by the impact will be minimal.W3C Membership. This means that OWL 2 will be backward compatible,is a draft document and creators of OWL 1may be updated, replaced or obsoleted by other documents need only move to OWL 2 when they want to make use of OWL 2 features. More details and advice concerning migration from OWL 1at any time. It is inappropriate to OWL 2 will be in future drafts. Summary of Changescite this document has been significantly updatedas other than work in several ways sinceprogress.

Patents

This document was produced by a group operating under the version5 February 2004 W3C Patent Policy. W3C maintains a public list of 11 April 2008. Usingany patent disclosures made in connection with the same URI to denote more than one typedeliverables of property is now disallowed, and so it usingthe same URI to denote both a class andgroup; that page also includes instructions for disclosing a datatype. The rolepatent. An individual who has actual knowledge of a URI in an ontology is determined by the declarations available inpatent which the ontology.individual believes contains Essential Claim(s) must disclose the terminal symbolsinformation in accordance with section 6 of the functional-style syntax have been simplified by removing "typed" variants. For example, insteadW3C Patent Policy.

[Show Short TOC]

Contents


1 Introduction

This document defines the OWL 2 semantics, annotations are treated as not being present. Instead,language. The usecore part of annotations is left tothis specification called the applications that use OWL 2. For example, a graphical user interface can choose to visualize each class using onestructural specification is independent of its labels. OWL 2 provides basic supportthe concrete exchange syntaxes for ontology modularization. In particular, anOWL 2 ontology O can import anotherontologies. It describes the conceptual structure of OWL 2 ontology O'ontologies and thus gain access to all entities, expressions, and axioms in O' . Concrete syntaxes, such as the functional-style syntax defined in this document, often provide features not found in the structural specification, such asprovides a mechanism for abbreviating long URIs. 1.1normative Status of this Document This document only defines the structural specificationabstract model for all (normative and nonnormative) syntaxes of OWL 2, the functional syntax2. This allows for OWL 2, and the behaviora clear separation of datatype maps. Onlythe partsessential features of the documentlanguage from issues related to these three purposes are normative. The examples in this document are informative andany partparticular syntax. Furthermore, such a structural specification of OWL 2 provides the document that is specifically noted as informative is not normative. Finally, the informal descriptions offoundation for the semanticsimplementation of OWL 2 constructs intools such as APIs and reasoners.

This document are informative;also defines the semantics is precisely specified in a separate document [functional-style syntax, which closely follows the structural specification and allows OWL 2 Direct Semantics ].ontologies to be written in a compact form. This syntax is used in the italicized keywords MUST , MUST NOT , SHOULD , SHOULD NOT , and MAY specify certain aspectsdefinitions of the normative behaviorsemantics of OWL 2 tools,ontologies, the mappings from and are interpretedinto the RDF/XML exchange syntax, and the different profiles of OWL 2. Concrete syntaxes, such as specifiedthe functional-style syntax, often provide features not found in RFC 2119 [ RFC 2119 ]. Section 2.1 states that "Duplicates SHOULD be eliminated [...] during parsing". This is to be interpretedthe structural specification, such as expected behavior ofa mechanism for abbreviating long URIs.

An OWL 2 tools, andontology is a formal conceptualization of a domain of interest. OWL 2 implementorsontologies consist of the following three different syntactic categories:

These three syntactic categories are expected to be intuitively understandableused to readers that are familiar withexpress the basic conceptslogical part of object-oriented systems, even ifOWL 2 ontologies that is, they are not familiar with UML. The names of abstract classes (i.e., the classesinterpreted under a precisely defined semantics that are not intendedallows useful inferences to be instantiated) are written in italic. Elementsdrawn. For example, if an individual a:Peter is an instance of the structural specification are connected by associations, many of which areclass a:Student, and a:Student is a subclass of one-to-many type. Whethera:Person, then from the elements participatingOWL 2 semantics one can derive that a:Peter is also an instance of a:Person.

In associations are orderedaddition, entities, axioms, and whether repetitions are allowed is made clear byontologies can be annotated in OWL 2. For example, a class can be given a human-readable label that provides an intuitive name for the following standard UML conventions: By default, all associations are sets;class. Annotations have no effect on the logical aspects of an ontology that is, for the elements in them are unordered and repetitionspurposes of the OWL 2 semantics, annotations are disallowed.treated as not being present. Instead, the { ordered,nonunique } attributeuse of annotations is placed nextleft to the association endsapplications that are ordereduse OWL 2. For example, a graphical user interface might choose to visualize a class using one of its labels.

Finally, OWL 2 provides basic support for ontology modularization. In particular, an OWL 2 ontology O can import another OWL 2 ontology O' and thus gain access to all entities, expressions, and axioms in which repetitions are allowed. Such associations have the semantics of lists. Whether two elementsO'.

1.1 Normative Status of this Document

This document defines the structural specification are considered to be the same is captured by the notionof structural equivalence , defined as follows. Elements o 1 and o 2 are structurally equivalent if and only ifOWL 2, the following conditions hold: If o 1functional syntax for OWL 2, and o 2 are atomic values, such as strings, integers, or IRIs (URIs), they are structurally equivalent if they are identical according tothe notionbehavior of identity specified bydatatype maps. Only the respective atomic type. If o 1 and o 2 are unordered associations without repetitions, they are structurally equivalent if each elementparts of o 1 is structurally equivalentthe document related to some element of o 2 and vice versa. If o 1 and o 2 are ordered associations with repetitions, theythese three purposes are structurally equivalent if they containnormative. The same number of elementsexamples in this document are informative and each elementany part of o 1the document that is structurally equivalent tospecifically identified as informative is not normative. Finally, the elementinformal descriptions of o 2 withthe same index. If o 1 and o 2 are complex elements consistingsemantics of other elements, they are structurally equivalent if both o 1 and oOWL 2 constructs in this document are ofinformative; the same type, each element of o 1semantics is structurally equivalent to the corresponding element of oprecisely specified in a separate document [OWL 2 Direct Semantics].

The italicized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and each associationMAY specify certain aspects of o 1 is structurally equivalent tothe corresponding associationnormative behavior of oOWL 2 . Notetools, and are interpreted as specified in RFC 2119 [RFC 2119].

Section 2.1 states that structural equivalence"Duplicates SHOULD be eliminated [...] during parsing". This is to be interpreted as specifying the expected behavior of OWL 2 tools, and OWL 2 implementors are expected to make their best effort to actually eliminate duplicates during parsing. An OWL 2 tool implementor may, however, choose not a semantic notion,to eliminate duplicates for various reasons, such as itperformance concerns. Provided that this design choice is based only on comparing structures.clearly documented, such deviation from this specification does not preclude the class expression UnionOf( a:Person a:Animal )tool from being comformant with the OWL 2 specification. The implementor is structurally equivalentstrongly encouraged, however, to provide a "no duplicates" mode for the class expression UnionOf( a:Animal a:Person ) becausecase when the user is willing to pay the orderperformance price.

2 Preliminary Definitions

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

2.1 UML Notation and Structural Equivalence

The elements in an unordered associationstructural specification of OWL 2 is not important.defined using the class expression UnionOf( a:Person ComplementOf( a:Person ) )Unified Modeling Language (UML) [UML], and the notation used is not structurally equivalent to owl:Thing even though these twocompatible with the Meta-Object Facility (MOF) [MOF]. This document uses only a very simple form of UML class expressionsdiagrams that are semantically equivalent. Although set associationsexpected to be intuitively understandable to readers who are widely used infamiliar with the specification, sets written in onebasic concepts of object-oriented systems, even if they are not familiar with UML. The linear syntaxes (e.g., XML or RDF/XML)names of abstract classes (i.e., classes that are not expectedintended to be duplicate free. Duplicates SHOULD be eliminated from such constructs during parsing. An ontologyinstantiated) are written in functional-style syntax can contain a class expressionitalic.

Elements of the form UnionOf( a:Person a:Animal a:Animal ) . During parsing, this expression should be "flattened" tostructural specification are connected by associations, many of which are of the expression UnionOf( a:Person a:Animal ) . 2.2 BNF Notationone-to-many type. Associations whose name is preceded by / are derived that is, their value is determined based on the functional-style syntaxvalue of OWL 2 is defined usingother associations and attributes. Whether the standard BNF notation, which is summarized in Table 1. Documents containing OWL 2 ontologies writtenelements participating in functional-style syntax SHOULD useassociations are ordered and whether repetitions are allowed is made clear by the UTF-8 encoding. Table 1.following standard UML conventions:

Whether two elements of the resulting IRI MUSTstructural specification are considered to be a valid IRI; otherwise,the functional-style syntax documentsame is syntactically invalid.captured by the value matching to abbreviated-IRI production is split into a prefix, matchingnotion of structural equivalence, defined as follows. Elements o1 and o2 are structurally equivalent if and only if the prefix production,following conditions hold:

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

The last namespace used here. URIs fromclass expression UnionOf( a:Person a:Animal ) is structurally equivalent to the rdf , rdfs , xsd , and owl namespaces constituteclass expression UnionOf( a:Animal a:Person ) because the reserved vocabularyorder of OWL 2. As described inthe following sections,elements in an unordered association is not important.

The URIs fromclass expression UnionOf( a:Person ComplementOf( a:Person ) ) is not structurally equivalent to owl:Thing even though the reserved vocabulary thattwo expressions are listed in Table 3 have special treatmentsemantically equivalent.

Although set associations are widely used in OWL 2. All other URIs from the reserved vocabulary constitutethe disallowed vocabularyspecification, sets written in one of OWL 2 and MUSTthe linear syntaxes (e.g., XML or RDF/XML) are not necessarily expected to be usedduplicate free. Duplicates SHOULD be eliminated from such constructs during parsing.

An ontology written in OWL 2 ontologies. Table 3. Reserved Vocabulary of OWL 2 with Special Treatment owl:backwardCompatibleWith owl:BottomDataProperty owl:BottomObjectProperty owl:dateTime owl:deprecated owl:incompatibleWith owl:Nothing owl:priorVersion owl:real owl:realPlus owl:Thing owl:TopDataProperty owl:TopObjectProperty rdf:langPattern rdf:text rdfs:comment rdfs:isDefinedBy rdfs:label rdfs:Literal rdfs:seeAlso xsd:anyURI xsd:base64Binary xsd:boolean xsd:byte xsd:decimal xsd:double xsd:ENTITY xsd:float xsd:hexBinary xsd:ID xsd:IDREF xsd:int xsd:integer xsd:language xsd:length xsd:long xsd:maxExclusive xsd:maxInclusive xsd:maxLength xsd:minExclusive xsd:minInclusive xsd:minLength xsd:Name xsd:NCName xsd:negativeInteger xsd:NMTOKEN xsd:nonNegativeInteger xsd:nonPositiveInteger xsd:normalizedString xsd:pattern xsd:positiveInteger xsd:short xsd:string xsd:token xsd:unsignedByte xsd:unsignedInt xsd:unsignedLong xsd:unsignedShort 2.4 Integers, Strings, Language Tags, and Node IDs Several typesfunctional-style syntax can contain a class expression of syntactic elements are commonly usedthe form UnionOf( a:Person a:Animal a:Animal ). During parsing, this expression should be "flattened" to give the expression UnionOf( a:Person a:Animal ).

2.2 BNF Notation

Grammars in this document. Nonnegative integersdocument are defined as usual. zero  := '0' nonZero  := '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' digit  :=specified using the standard BNF notation, summarized in Table 1.

Table 1. The BNF Notation
Construct Syntax Example
nonterminal symbols boldface ClassExpression
terminal symbols single quoted 'PropertyRange'
zero | nonZero postiveInteger  := nonZeroor more curly braces { digitClassExpression }
nonNegativeInteger  :=zero or one square brackets [ ClassExpression ]
alternative vertical bar Assertion | positiveInteger CharactersDeclaration

Terminal symbols used in the full-IRI, irelative-ref, NCName, languageTag, nodeID, nonNegativeInteger, and stringsquotedString productions are defined in the same way as in [ RDF:TEXT ]. A character is an atomic unit of communication. Theby specifying their structure of characters is not further specifiedin OWL 2, other thanEnglish; to note that each character has a Universal Character Set (UCS) code point [ ISO/IEC 10646 ].stress this, the set of available charactersEnglish description is assumed to be infinite, and it thus independent from the currently actual version of UCS. A stringitalicized.

Whitespace is a finitemaximal sequence of characters,space (U+20), horizontal tab (U+9), line feed (U+A), and the lengthcarriage return (U+D) characters not occurring within a pair of " characters (U+22). A stringcomment is the numbera maximal sequence of characters in it. Inthat starts with the functional-style syntax, strings are written as specified in [ RDF:TEXT ]: they are enclosed in double quotes,# (U+23) character and contains neither a subsetline feed (U+A) nor a carriage return (U+D) character.

Whitespace and comments cannot occur within terminal symbols of the quoting mechanismgrammar. Whitespace and comments can occur between any two terminal symbols of the N-triples specification [ RDF Test Cases ] is used to encode strings containing quotes. quotedString  := '"'grammar, and all whitespace MUST be ignored. Whitespace MUST be introduced between a finite sequencepair of terminal symbols if each terminal symbol in the pair consists solely of alphanumeric characters with double quotes and backslashes replaced byor matches the double quotefull-IRI, irelative-ref, NCName, nodeID, or backslash preceded by a backslash '"' Language tagsquotedString production.

2.3 URIs and Namespaces

Ontologies and their elements are nonempty strings as defined in BCP 47identified using International Resource Identifiers (IRIs) [ BCP 47RFC3987]. OWL 1 uses Uniform Resource Identifiers (URIs) as identifiers. To avoid introducing new terminology, this specification hereafter uses the term "URI" to mean "IRI". In the functional-style syntax, language tagsstructural specification, IRIs are not enclosedrepresented by the URI class.

All IRIs in double quotes; however,this does not lead to parsing problems since, according to BCP 47, language tags contain neither whitespace norspecification are written using the parentheses '(' and ')'. languageTag  :=grammar described below. Thus, an IRI can be written as a nonempty (not quoted) string definedfull IRI, or it can be abbreviated as specified in BCP 47 [ BCP 47 ] Node IDs are borrowed from the N-Triples specificationa CURIE [ RDF Test CasesCURIE]. nodeID  := a node ID forTo facilitate the form _: name as specifiedlatter, commonly used IRIs called namespaces are associated with a prefix. An IRI U belongs to a namespace NU if, in their string representation, NU is a prefix of U; the N-Triples specification [ RDF Test Cases ] 3 Ontologies The main componentpart of an OWL 2 ontologyU not covered by NU is called a reference of U w.r.t. NU. A URI U belonging to a namespace NU associated with a prefix pref is then commonly abbreviated as a CURIE pref:ref, where ref is the setreference of axioms thatU w.r.t. NU. CURIEs are not represented in the ontology contains. Because an ontology consistsstructural specification of OWL 2: if a setconcrete syntax of axioms, an ontology cannot contain two axioms that are structurally equivalent.OWL 2 ontology documents are not expecteduses CURIEs to enforce this; however, when reading OWL 2 ontologies stored in documents, an OWL 2 implementationabbreviate long IRIs, these abbreviations MUST eliminate structurally equivalent duplicate axioms.be expanded into full IRIs during parsing according to the structurerules of axioms is describedthe respective syntax.

full-IRI:= 'IRI as defined in more detail[RFC3987], enclosed in Section 9 . Apart from axioms, ontologies can also contain annotations,a pair of < (U+3C) and they can import other ontologies> (U+3E) characters'
NCName:= 'as well. The structure of OWL 2 ontologies is showndefined in Figure 1. Figure 1. OWL Ontologies ontologyDocument  := { namespaceDefinition } Ontology namespaceName  := full-IRI namespaceDefinition  := 'Namespace' '('[ prefixXML Namespaces] '=' namespaceName ')' ontologyURI  := URI versionURI  := URI import  := 'Import' '(' URI ')' Ontology  :=     'Ontology' '(''
irelative-ref:= 'as defined in [ ontologyURIRFC3987]'

namespace:= full-IRI
prefix:= NCName
reference:= irelative-ref
curie:= [ versionURI[ prefix ] ':' ]        { import }        { Annotation }        { Axiom }     ')'reference

URI:= full-IRI | curie

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

Table 2. Standard Namespaces and Prefixes Used in OWL 2
Namespace production defines an abbreviation forprefix Namespace
rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
rdfs <http://www.w3.org/2000/01/rdf-schema#>
xsd <http://www.w3.org/2001/XMLSchema#>
owl <http://www.w3.org/2002/07/owl#>

IRIs belonging to the rdf, rdfs, xsd, and owl namespaces constitute the reserved vocabulary of OWL 2. As described in the following sections, the IRIs from the reserved vocabulary that are listed in a document.Table 3 have special treatment in each document, only one namespace declaration MUST exist for a given prefix . These prefixes are then used to expand abbreviatedOWL 2. All IRIs as specifiedfrom the reserved vocabulary not listed in Section 2.3 .Table 3 constitute the following is andisallowed vocabulary of OWL 2 and MUST NOT be used in OWL 2 to name entities, ontologies, or ontology versions.

Table 3. Reserved Vocabulary of OWL 2 with an ontology URI http://example.org/ontology1 that imports an ontology http://example.org/ontology2Special Treatment
owl:backwardCompatibleWith owl:bottomDataProperty owl:bottomObjectProperty owl:dateTime owl:deprecated
owl:incompatibleWith owl:Nothing owl:priorVersion owl:rational owl:real
owl:realPlus owl:Thing owl:topDataProperty owl:topObjectProperty rdf:langPattern
rdf:text rdf:XMLLiteral rdfs:comment rdfs:isDefinedBy rdfs:label
rdfs:Literal rdfs:seeAlso xsd:anyURI xsd:base64Binary xsd:boolean
xsd:byte xsd:decimal xsd:double xsd:float xsd:hexBinary
xsd:int xsd:integer xsd:language xsd:length xsd:long
xsd:maxExclusive xsd:maxInclusive xsd:maxLength xsd:minExclusive xsd:minInclusive
xsd:minLength xsd:Name xsd:NCName xsd:negativeInteger xsd:NMTOKEN
xsd:nonNegativeInteger xsd:nonPositiveInteger xsd:normalizedString xsd:pattern xsd:positiveInteger
xsd:short xsd:string xsd:token xsd:unsignedByte xsd:unsignedInt
xsd:unsignedLong xsd:unsignedShort

2.4 Integers, Strings, Language Tags, and that contains an ontology annotation that providesNode IDs

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

nonNegativeInteger:= 'a label for the ontologynonempty finite sequence of digits between 0 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 URI9'

Characters and Version URI Each ontology MAY have an ontology URI , whichstrings are defined in the same way as in [RDF:TEXT]. A character is used to identify an ontology. If an ontology hasan ontology URI,atomic unit of communication. The ontology MAY additionally havestructure of characters is not further specified in OWL 2, other than to note that each character has a version URI , whichUniversal Character Set (UCS) code point [ISO/IEC 10646]. The set of available characters is usedassumed to identifybe infinite, and is thus independent from the currently actual version of the ontology. The version URI MAY , but need not be equal to the ontology URI. An ontology without an ontology URI MUST NOT containUCS. A version URI. To prevent problems with identifying ontologies, the following nonnormative guidancestring is provided: If an ontology has an ontology URI but no version URI, thena different ontology with the same ontology URI but no version URI SHOULD NOT exist. If an ontology has both an ontology URIfinite sequence of characters, and the length of a version URI, then a different ontology withstring is the same ontology URInumber of characters in it. In this document, strings are written as specified in [RDF:TEXT]: they are enclosed in double quotes, and a subset of the same version URI SHOULD NOT exist. All other combinationsescaping mechanism of the ontology URI and version URI are not requiredN-triples specification [RDF Test Cases] is used to be unique. Thus, two different ontologies MAY have no ontology URI and no version URI; similarly, an ontologyencode strings containing quotes.

quotedString:= 'a finite sequence of characters in which " (U+22) and \ (U+5C) occur only an ontology URI MAY coexist with another ontology within pairs of the form \" (U+22, U+5C) and \\ (U+22, U+22), enclosed in a pair of " (U+22) characters'

Language tags are nonempty strings as defined in BCP 47 [BCP 47]. In this document, language tags are not enclosed in double quotes; however, this does not lead to parsing problems since, according to BCP 47, language tags contain neither whitespace nor the same ontology URIparenthesis characters ( (U+28) and some other version URI. This specification provides no mechanism for enforcing these constraints) (U+29).

languageTag:= 'a nonempty (not quoted) string defined as specified in BCP 47 [BCP 47]'

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

nodeID:= 'a node ID of the presented rules are to be takenform _:name as guidelines when naming new ontologies, and they MAY be used byspecified in the N-Triples specification [RDF Test Cases]'

3 Ontologies

An OWL 2 tools to detect problems. Theontology URIis the main part of the structural specification, and its structure is shown in Figure 1. The version URI together identify a particular version frommain component of an OWL 2 ontology series — theis its set of allaxioms, the versionsstructure of a particular ontology identified using a common ontology URI. In each ontology series, exactly one ontology versionwhich is regarded asdescribed in more detail in Section 9. Because the current one. Structurally, a version of a particularassociation between an ontology and its axioms is a set, an instance ofontology cannot contain two axioms that are structurally equivalent. Apart from the structural specification.axioms, ontologies can also contain ontology series are not represented explicitlyannotations (as described in the structural specification of OWL 2; therefore,more detail in Section 3.5), and they exists only as a side-effect of the naming conventionscan also import other ontologies (as described in this andSection 3.4).

OWL Ontologies
Figure 1. The following sections. 3.2 LocationsStructure of OWL 2 Ontologies

The3.1 Ontology URI and theVersion URI, if present, determine the location of anURI

Each ontology O according to the following rules: If O does not containMAY have an ontology URI (and, consequently,, which is without a version URI as well), then O MAY be located anywhere.used to identify an ontology. If O containsan ontology URI ou but no versionhas an ontology URI, then O SHOULD be located atthe location ou . If O contains anontology URI ou andMAY additionally have a version URI vu, then O SHOULD be located at the location vu ; furthermore, if Owhich is used to identify the currentversion of the ontology series with the URI ou , then it SHOULD also be located at the location ou . Thus,ontology. The currentversion of an ontology series with someURI ou SHOULD be accessed from ou . To access a particular version of ouMAY, one needsbut need not be equal to know that version's version URI vu ; then,the ontology SHOULD be accessed from vu .URI. An ontology O containingwithout an ontology URI http://www.my.com/example but noMUST NOT contain a version URI should be located atURI.

To prevent problems with identifying ontologies, the address http://www.my.com/example . In contrast,following nonnormative guidance is provided:

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

The tool can redirect thisontology URI to file:/C:/Temp/example.owland retrievethe ontologyversion URI together identify a particular version from there. The retrievedan ontology should satisfyseries the location constraints: ifset of all the versions of a particular ontology contains only theidentified using a common ontology URI, then theURI. In each ontology URI should be equal to http://www.my.com/example , and ifseries, exactly one ontology version is regarded as the current one. Structurally, a version of a particular ontology is an instance of the Ontology contains bothclass from the structural specification. Ontology andseries are not represented explicitly in the version URI, then one of them should be equal to http://www.my.com/example . 3.3 Versioningstructural specification of OWL 2 Ontologies2; therefore, they exists only as a side-effect of the naming conventions regarding the location of ontologiesdescribed in Sectionthis and the following sections.

3.2 provide a simple mechanism for versioningOntology Documents

An OWL 2 ontologies. Anontology seriesis identified usingan ontology URI, and each versionabstract notion defined in terms of the seriesstructural specification. Each ontology is assigned a different version URI.associated with an ontology document, which physically contains the ontology representingstored in a particular way. Ontology documents are not represented in the current versionstructural specification of OWL 2, and the series SHOULD be located atspecification of OWL 2 makes only the ontology URI and, if present, at its version URI as well; previous versions are located solely atfollowing two assumptions about their respective version URIs. Whennature:

The ontology URI (and it SHOULD alsoname "ontology document" reflects the expectation that a large number of ontologies will be accessible from its version URI).stored in physical text documents written in one of the current versionsyntaxes of OWL 2. OWL 2 tools, however, are free to devise other types of anontology series might be located atdocuments that is, to introduce other ways of physically storing ontologies.

For example, an OWL 2 tool can devise a URI http://www.my.com/example , as well as the location http://www.my.com/example/2.0/scheme for the particular version. Whenstoring a new version is created,set of OWL 2 ontologies in a relational database. In such a case, each subset of the previous version should remain accessible at http://www.my.com/example/2.0/ ;database representing 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 Aninformation about one ontology can import other ontologies in ordercorresponds to gain accessone ontology document. To their entities, expressions, and axioms, thus providingprovide a mechanism for accessing these ontology modularization. Assume that one wants to describe research projects about diseases. Managing information about the projects and the diseases indocuments, the sameOWL 2 tool should identify different database subsets with distinct URIs.

3.2.1 Functional-Style Syntax Ontology might be cumbersome. Therefore, one might createDocuments

A separatefunctional-style syntax ontology O about diseases anddocument is a separate ontology O' about projects.sequence of Unicode characters [UNICODE] accessible from some URI by means of the standard protocols. A functional-style syntax ontology O' would import O in order to gain access to the classes representing diseases; intuitively, this allows one todocument SHOULD use the diseases from O when writingUTF-8 encoding [RFC3629]; its text MUST must match the axiomsontologyDocument production of O' . Figure 1 presentsthe logical viewgrammar defined in this specification document; and it MUST be possible to convert the ontology document into an ontology by means of the import relation, which holds between two ontologies . In concrete syntaxes, however,canonical parsing process described in Section 5.8.3.

ontologyDocument:= { prefixDefinition } Ontology
prefixDefinition:= 'Namespace' '(' [ prefix ] '=' namespace ')'
Ontology:=
'Ontology' '(' [ ontologyURI [ versionURI ] ]
directlyImportsDocuments
ontologyAnnotations
axioms
')'
ontologyURI:= URI
versionURI:= URI
directlyImportsDocuments:= { 'Import' '(' URI ')' }
axioms:= { Axiom }

The following is a functional-style syntax ontology document containing an ontology with the importingontology only contains aURI identifying the location of the imported ontology.<http://www.example.com/ontology1>. This location SHOULD be interpreted as specified in Section 3.2 in order to access the imported ontology. Assume that anontology Oimports anotheran ontology O'whose ontology document should be accessed from <http://www.example.com/ontology2>, which hasand it contains an ontology annotation providing a label for the ontology URI http://www.my.com/example/and a single subclass axiom.

Ontology(<http://www.example.com/ontology1>
Import(<http://www.example.com/ontology2>)
Annotation( rdfs:label "The example")

SubClassOf( a:Child a:Person )
)

Each part of the version URI http://www.my.com/example/2.0/ . Inontology document matching the prefixDefinition production associates a concrete syntax, O wouldprefix with a namespace. An ontology document MUST contain at most one such definition per prefix, and it MUST NOT contain a definition for a prefix listed in Table 2. Prefix definitions are used during parsing to expand CURIEs in the locationontology document that is, parts of O' ; inthe functional-style syntax, O would be writtenontology document matching the curie production into full URIs as follows.

The full URI obtained by this expansion MUST be a transitive closurevalid URI. If an ontology document does not satisfy all of the relation directly imports . Finally, the import closure of O consists of O and eachspecified conditions, it is syntactically invalid.

3.2.2 Accessing OWL 2 Ontology that O imports.Documents

The import closureontology document of an ontology O SHOULD be accessible from the URIs determined by the following rules:

Thus, the document containing the current version of an ontology series with all anonymous individuals renamed apart —some URI OU SHOULD be accessible from OU. To access a particular version of OU, one needs to know that is,version's version URI VU; then, the anonymous individualsontology document SHOULD be accessible from different ontologies in the import closureVU.

An ontology document of O are treated as being different; please refer to Section 5.6.2 for more information. In OWL 1, owl:imports was a specialan ontology property that was used to specifythat contains an ontology imports another ontology. In OWL 2, imports are not ontology annotations,URI <http://www.example.com/my> but are a separate primitive; the owl:imports annotation property hasno built-in meaningversion URI should be accessible from the URI <http://www.example.com/my>. In OWL 2. 3.5contrast, an ontology Annotationsdocument of an OWL 2ontology that contains a set of annotations. These can be used to associate information withan ontology such asURI <http://www.example.com/my> and a version URI <http://www.example.com/my/2.0> should be accessible from the ontology creator's name. As discussed in Section 10URI <http://www.example.com/my/2.0>. In more detail, each annotation consists of an annotation property and an annotation value, andboth cases, the latter can be a literal, an entity, or an anonymous individual.ontology annotations do not affectdocument should be accessible from the logical meaning ofrespective URIs using the ontology.HTTP protocol.

OWL 2 provides several built-in annotation properties fortools will often need to implement functionality such as caching or off-line processing, where ontology annotations.documents may be stored at addresses different from the usage of these annotation properties on entities other than ontologiesones as dictated by their ontology URIs and version URIs. OWL 2 tools MAY implement a redirection mechanism: when a tool is discouraged.used to access an owl:priorVersion annotation value isontology document at URIU, the tool MAY redirect U to a different URI DU and access the location ofontology document from there instead. The prior versionresult of accessing the containing ontology. An owl:backwardCompatibleWith annotation value isontology document from DU MUST be the location of a prior version ofsame as if the containingontology thatwere accessed from U. Furthermore, once the ontology document is compatible with this ontology.converted into an owl:incompatibleWith annotation value isontology, the location of a prior versionontology SHOULD satisfy the three conditions from the beginning of this section in the same way as if it the containingontology that is incompatible withdocument were accessed from U. This ontology. 4 Datatype Maps OWL 2 ontologies can contain values with built-in semantics, such as strings or integers. Such valuesspecification does not specify any particular redirection mechanisms these are often called concrete , in orderassumed to be implementation dependent.

To enable off-line processing, an ontology document that according to distinguish them from the abstract values which are modeled using classes and individuals. Each kind of such values is called a datatype , andthe set of all supported datatypes is calledabove rules should be accessible from <http://www.example.com/my> might be stored in a datatype mapfile accessible from <file:///usr/local/ontologies/example.owl>. A datatype map is not a syntactic construct that is included intoTo access this ontology document, an OWL 2 ontologies; therefore, it is not included intool might redirect the structural specification of OWL 2. A datatype in a datatype map is identified by aURI <http://www.example.com/my> and actually access the ontology document from <file:///usr/local/ontologies/example.owl>. The ontology obtained after accessing ontology document should satisfy the usual accessibility constraints: if the ontology contains only the ontology URI, then the ontology URI should be equal to <http://www.example.com/my>, and it canif the ontology contains both the ontology URI and the version URI, then one of them should be used in anequal to <http://www.example.com/my>.

3.3 Versioning of OWL 2 ontology as described in Section 5.2 . More precisely, a datatype map is a 6-tuple D = ( N DT , N LT , N FA , ⋅  DT , ⋅  LT , ⋅  FA ) withOntologies

The following components. N DT isconventions from Section 3.2.2 provide a set of datatypes, each of whichsimple mechanism for versioning OWL 2 ontologies. An ontology series is identified by ausing an ontology URI, not containingand each version in the datatype rdfs:Literal . N LTseries is assigned a function that assigns to each datatype DT ∈ N DT a setdifferent version URI. The ontology document of literals N LT (DT) .the set N LT (DT) is calledontology representing the lexical spacecurrent version of DT .the setseries SHOULD be accessible from the ontology URI and, if present, at its version URI as well; the ontology documents of all literals for all datatypesthe previous versions SHOULD be accessible solely from their respective version URIs. When a new version O in Dthe ontology series is denotedcreated, the ontology document of O SHOULD replace the one acessible from the ontology URI (and it SHOULD also with N LT ; whether N LT is used as a function or asbe accessible from its version URI).

The setontology document containing the current version of all literals is expected toan ontology series might be clearaccessible from the URI <http://www.example.com/my>, as well as from the context. A literal forversion-specific URI <http://www.example.com/my/2.0>. When a datatype DT has the form "abc"^^ DT , where abcnew version is a string calledcreated, the lexical valueontology document of the literal. N FA is a function that assigns to each datatype DT ∈ N DT a set N FA (DT) of pairsprevious version should remain accessible from <http://www.example.com/my/2.0>; the ontology document of the form ⟨ f lt ⟩ , where f is a constraining facetnew version, called, say, <http://www.example.com/my/3.0>, each of which is identified by a URI,should be made accessible from both <http://www.example.com/my> and lt ∈ N LT<http://www.example.com/my/3.0>.

Note that lt3.4 Imports

An OWL 2 ontology can be a literal of a datatypeimport other than DT . The set N FA (DT) is calledontologies in order to gain access to their entities, expressions, and axioms, thus providing the facet space of DT .basic facility for each datatype DT ∈ N DT , the interpretation function ⋅  DT assignsontology modularization.

Assume that one wants to DT a set (DT) DT calleddescribe research projects about diseases. Managing information about the value space . For each datatype DT ∈ N DTprojects and each literal lt ∈ N LT (DT) ,the interpretation function ⋅  LT assigns to ltdiseases in the same ontology might be cumbersome. Therefore, one might create a data value (lt) LT ∈ (DT) DT . For each datatype DT ∈ N DTseparate ontology O about diseases and each pair ⟨ f lt ⟩ ∈ N FA (DT) ,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 interpretation function ⋅  FA assigns to ⟨ f lt ⟩ a facet value ( ⟨ f lt ⟩ ) FA ⊆ (DT) DT . For simplicity, statementsaxioms of the form "the valueO'.

From a physical point of view, an ontology contains a literal isset of URIs, shown in Figure 1 as the value spacedirectlyImportsDocuments association, that identify the ontology documents of a certain datatype" are sometimes informally abbreviatedthe directly imported ontologies. These URIs SHOULD be interpreted as specified in Section 3.2.2 to statementsaccess the ontology documents and convert them into ontologies; the result of this process determines the form "a literal islogical directly imports relation between ontologies, shown in a certain datatype"Figure 1 as the directlyImports association. The logical imports relation between ontologies, shown in this specification. To include a datatype DT into a datatype map, one thus needs to provideFigure 1 as the lexical space N LT (DT) ,imports association, is the facet space N FA (DT) ,transitive closure of directly imports. In Figure 1, associations directlyImports and imports are shown as derived associations, since their values are derived from the value space (DT) DT ,of the value (lt) LT for each lt ∈ N LT (DT) ,directlyImportsDocuments association; furthermore, ontology documents usually provide means to store the directlyImportsDocuments association, but not the directlyImports and a facet value ( ⟨ f lt ⟩imports associations.

The following functional-style syntax ontology document contains an ontology that directly imports an ontology contained in the ontology document accessible from URI <http://www.example.com/my/2.0>.

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

FA for each ⟨ f lt ⟩ ∈ N FA (DT)...
)

The URIs identifying the ontology documents of the directly imported ontologies can be redirected as described in Section 3.2.2. Such a specification is often identified with DT and is often also called a datatype;For example, in order to access the intended meaning ofontology document from a local cache, the term "datatype" is expectedontology document <http://www.example.com/my/2.0> might be redirected to <file:///usr/local/ontologies/imported.v20.owl>. Note that this can be clear from the context.done without changing the OWL 2 datatype map consistsontology document of datatypes described inthe rest of this section, mostimporting ontology.

The import closure of which are based on XML Schema Datatypes [ XML Schema Datatypes ].an ontology O is a set containing O all all ontologies that O imports. The definitionsimport closure of these datatypes in OWLO SHOULD NOT contain ontologies O1 and O2 such that

The semantic consequencesaxiom closure of an ontology depend exclusively onO is the smallest set of actually used datatypes. Implementations are therefore free to extendthat contains all the datatype map describedaxioms from each ontology O' in this section with extra datatypes without affectingthe consequencesimport closure of OWL 2 ontologiesO with all anonymous individuals renamed apart that do not use these datatypes. 4.1 Numbers OWL 2 provides a rich set of datatypes, listedis, the anonymous individuals from different ontologies in Table 4, for representing various kinds of numbers. Value Spaces.the value spacesimport closure of all numeric datatypesO are showntreated as being different; see Section 5.6.2 for further details.

In Table 4. The value space of owl:realPlus containsOWL 1, owl:imports was a special ontology property that was used to identify the value spacesontology documents of all other numeric datatypes.the special values -0 , +INF , -INF , and NaN are not identical to any number.imported ontologies. In particular, -0 isOWL 2, imports are not ontology properties, but are a real number and it is not identical to real number zero; to stress this distinction,separate primitive; thus, the real number zero is often calledowl:imports ontology property has no built-in meaning in OWL 2.

3.5 Ontology Annotations

An OWL 2 ontology contains a positive zero , written +0 . Table 4. Numeric Datatypes and Their Value Spaces Datatype Value Space owl:realPlus theset of all real numbers extendedannotations. These can be used to associate information with four special values -0 ( negative zero ), +INF ( positive infinity ), -INF ( negative infinity ), and NaN ( not-a-number ) owl:real the set of all real numbers xsd:double the four special values -0 , +INF , -INF , and NaN , plusan ontology such as the set of all real numbersontology creator's name. As discussed in Section 10 in more detail, each annotation consists of the form m × 2 e where m is an integer whose absolute value is less than 2 53 and e isan integer between -1075annotation property and 970, inclusive xsd:float the four special values -0 , +INF , -INF ,an annotation value, and NaN , plusthe set of all real numberslatter can be a literal, a URI, or an anonymous individual. Ontology annotations do not affect the logical meaning of the form m ×ontology.

ontologyAnnotations:= { Annotation }

OWL 2 e where m is an integer whose absolute value is lessprovides several built-in annotation properties for ontology annotations. The usage of these annotation properties on entities other than 2 24 and eontologies is an integer between -149 and 104, inclusive xsd:decimaldiscouraged.

4 Datatype Maps

OWL 2 ontologies can contain values with built-in semantics, such as strings or integers. Such values are often called concrete, in order to distinguish them from the abstract values which are modeled using classes and 4294967295, inclusive xsd:unsignedShort the setindividuals. Each kind of all integers between 0such values is called a datatype, and 65535, inclusive xsd:unsignedBytethe set of all integers between 0 and 255, inclusive Literals.supported datatypes owl:realPlus and owl:real dois called a datatype map. A datatype map is not directly provide any literals —a syntactic construct that is, no "abc"^^owl:realPlus ( "abc"^^owl:real )is a literalincluded into OWL 2 ontologies; therefore, it is not included in the structural specification of owl:realPlus ( owl:real). For DTOWL 2. Each datatype in a datatype different from owl:realPlusmap is identified by a URI, and owl:real ,it can be used in an OWL 2 ontology as described in Section 5.2.

More precisely, a literal of the form "abc"^^DTdatatype map is a literal of6-tuple D = ( NDT , NLS , NFS , DT , LS , FS ) with the following components.

To include a type derived from xsd:integer isdatatype DT into a core literal if its data value is indatatype map, one thus needs to provide the lexical space NLS(DT), the facet space NFS(DT), the value space of xsd:long . A literal of type xsd:decimal is a core literal if its(DT)DT, the data value is( LV DT )LS for each LV NLS(DT), and a number with absolutefacet value less than 10 16( F V )FS for each F V NFS(DT). Such a specification is often identified with DT and is usually also called a datatype; the representationintended meaning of the number requires at most 16 digitsterm "datatype" is expected to be clear from the context.

The OWL 2 datatype map consists of datatypes described in total. Editor's Note:the newrest of this section, most of which are based on XML Schema spec contains an acknowledged editorial errorDatatypes, version 1.1 [XML Schema Datatypes]. The definitions of these datatypes in OWL 2 are largely the definitionsame as in XML Schema; however, there are minor differences, all of core literals for xsd:decimal .which are clearly identified in the spec will be updatedfollowing sections. These differences were introduced mainly to state that core decimal literals are those that can be expressedalign the semantics of OWL 2 datatypes with sixteen decimal digits, as is stated here. This document will be updated topractical use the wordingcases.

As shown in the XML Schema spec ifOWL 2 Direct Semantics [OWL 2 Direct Semantics], the change there is madesemantic consequences of an ontology depend exclusively on the set of actually used datatypes. Implementations are therefore free to extend the datatype map described in time. Equality and Ordering.this section with extra datatypes without affecting the facet spaceconsequences of OWL 2 ontologies that do not use these datatypes.

4.1 Numbers

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

Value Spaces. The value spaces of all numeric datatypes are based on the following definitions of equality and ordering. The equality = is the smallest symmetric relation onshown in Table 4. The value space of owl:realPlus such that allcontains the value spaces of all other numeric datatypes. The following conditions hold: x = x if x is a real number,special values -0, +INF, -INF, or +INF ;and -0 = +0 . Note thatNaN isare not equalidentical to itself; furthermore, even thoughany number. In particular, -0 is equal to +0 ,not a real number and it is not identical to it.real number zero; to understandstress this distinction, the distinctionreal number zero is often called a positive zero, written +0.

Table 4. Numeric Datatypes and Their Value Spaces
Datatype Value Space
owl:realPlus the set of all real numbers extended with four special values -0 (negative zero), +INF (positive infinity), -INF (negative infinity), and NaN (not-a-number)
owl:real the set of all real numbers
owl:rational the set of all rational numbers
xsd:double the four special values -0, +INF, -INF, and NaN, plus the set of all real numbers of the form m 2e where m is an integer whose absolute value is less than 253 and e is an integer between identity-1075 and 970, inclusive
xsd:float the four special values -0, +INF, -INF, and equality, considerNaN, plus the following example ontology: PropertyAssertion( a:Meg a:numberOfChildren "+0"^^xsd:float )set of all real numbers of the form m 2e where m is an integer whose absolute value of a:numberOfChildren for a:Megis +0 . PropertyAssertion( a:Meg a:numberOfChildren "-0"^^xsd:float )less than 224 and e is an integer between -149 and 104, inclusive
xsd:decimal the valueset of a:numberOfChildren for a:Megall real numbers of the form i 10-n where i is -0 . FunctionalProperty( a:numberOfChildren )an individual can have only one value for a:numberOfChildren . The last axiom states that no individual should have more than one distinct value for a:numberOfChildren . Even though positiveinteger and negative zeros are equal, they are distinct values ; hence,n is a nonnegative integer
xsd:integer the first two axioms violateset of all integers
xsd:nonNegativeInteger the restrictionset of all nonnegative integers
xsd:nonPositiveInteger the last axiom, which leads to inconsistency.set of all negative integers plus (positive) zero
xsd:positiveInteger the ordering < isset of all positive integers
xsd:negativeInteger the smallest relation onset of all negative integers
xsd:long the value spaceset of owl:realPlus such thatall integers between -9223372036854775808 and 9223372036854775807, inclusive
xsd:int the set of all integers between -2147483648 and 2147483647, inclusive
xsd:short the following conditions hold: x < y if xset of all integers between -32768 and y are real numbers32767, inclusive
xsd:byte the set of all integers between -128 and x is smaller than y ; -INF < x < +INF for each real number x ; -0 < x for each positive real number x ;127, inclusive
xsd:unsignedLong the set of all integers between 0 and x < -0 for each negative real number x . According to18446744073709551615, inclusive
xsd:unsignedInt the above definition,set of all integers between 0 and 4294967295, inclusive
xsd:unsignedShort the subsetset of all integers between 0 and 65535, inclusive
xsd:unsignedByte the value spaceset of owl:realPlusall integers between -10 and 1 contains both +0255, inclusive

Feature At Risk #1: owl:rational support

Note: This feature is "at risk" and -0may be removed from this specification based on feedback. Please send feedback to public-owl-comments@w3.org.

Facet Space.The facet space of each numericowl:rational datatype DT is shown in Table 5. Note that lt canmight be a literal of a numeric datatype other than DT . Table 5.removed from OWL 2 if implementation experience reveals problems with supporting this datatype.

Lexical Sapce. Datatypes owl:realPlus and owl:real do not directly provide any lexical values.

The Facet Space of a Numericowl:rational datatype DT Pair Facet Value ⟨ xsd:minInclusive lt ⟩ where lt is a numeric literalsupports lexical values defined by the set of all numbers x ∈ (DT) DT such that x = (lt) LT or x > (lt) LT ⟨ xsd:maxInclusive lt ⟩ where lt is a numeric literalfollowing grammar (whitespace within the setgrammar MUST be ignored and MUST NOT be included in the lexical values of all numbers x ∈ (DT) DT such that x = (lt) LT or x < (lt) LT ⟨ xsd:minExclusive lt ⟩owl:dateTimte, and single quotes are used to introduce terminal symbols):

numerator '/' denominator

where ltnumerator is a numeric literalan integer with the set of all numbers x ∈ (DT) DT such that x > (lt) LT ⟨ xsd:maxExclusive lt ⟩ where ltsyntax as specified for the xsd:integer datatype, and denominator is a numeric literalpositive, nonzero integer with the syntax as specified for the set of all numbers x ∈ (DT) DTxsd:integer datatype, not containing the plus sign. Each such that x < (lt) LT Relationshiplexical value of owl:rational is mapped to the rational number obtained by dividing numerator with denominator.

For DT a datatype from XML Schema. Numeric datatypesschema, lexical values of OWL 2DT are closely related to numeric datatypesdefined as specified in XML Schema Datatypes [XML Schema Datatypes ]; however, they differ from]. Furthermore, each pair "abc" DT is assigned a data value by interpreting "abc" as specified in XML Schema Datatypes in[XML Schema Datatypes] for DT.

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

Feature At Risk #2: xsd:decimal precision

Note: This feature is "at risk" and xsd:double aremay be removed from this specification based on feedback. Please send feedback to public-owl-comments@w3.org.

The new XML Schema spec contains an acknowledged editorial error in OWL 2 NOT disjoint withthe value spacedefinition of core lexical values for xsd:decimal. The value spaces of owl:realPlus , xsd:float , and xsd:double contain negative zero. InThis way, the datatype system of OWL 2 has been aligneddocument will be updated to state that core decimal lexical values are those that can be expressed with the IEEE 754 [ IEEE 754 ] standard for the representation of floating-point numbers. The special value NaNsixteen decimal digits, as is identical but not equalstated here. This document will be updated to itself. 4.2 Strings 4.2.1 Strings with a Language Tag OWL 2 usesuse the rdf:text datatype [ RDF:TEXT ] forwording in the representation of stringsXML Schema spec if the change there is made in a particular language.time.

Equality and Ordering. The notionfacet space of a string used inthe definitionnumeric datatypes are based on the following definitions of rdf:textequality and ordering.

The equality = is the same as in Section 2.4 . Value Space.smallest symmetric relation on the value space of rdf:text is the set ofowl:realPlus such that all pairsof the form ⟨ " text " , " lang " ⟩ , where " text "following conditions hold:

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

To understand the empty string "" or a lowercase language tag as specified in BCP 47 [ BCP 47 ]. Literals.distinction between identity and equality, consider the rdf:text datatype supports literalsfollowing example ontology:

PropertyAssertion( a:Meg a:numberOfChildren "+0"^^xsd:float ) The value of a:numberOfChildren for a:Meg is +0.
PropertyAssertion( a:Meg a:numberOfChildren "-0"^^xsd:float ) The form "val"^^ rdf:text , where "val"value of a:numberOfChildren for a:Meg is a string that contains-0.
FunctionalProperty( a:numberOfChildren ) An individual can have at leastmost one character @value for a:numberOfChildren.

The last axiom states that no individual should have more than one distinct value for a:numberOfChildren. Even though positive and satisfiesnegative zeros are equal, they are distinct values; hence, the following condition: let i befirst two axioms violate the positionrestriction of the last character @ in "val" , and let "abc" and "tag" beaxiom, which leads to inconsistency.

The substringsordering < is the smallest relation on the value space of owl:realPlus such that all of "val" containingthe characters up tofollowing conditions hold:

Note that +0 is assigneda data value ⟨ "abc", "lc-tag" ⟩ , where "lc-tag"real number and is thus covered by the string "tag" converted to lowercase. Literal "Family Guy@en"^^ rdf:text is mappedfirst two cases.

According to the data value ⟨ "Family Guy , "en" ⟩ , and "Family Guy@"^^ rdf:text is mapped to ⟨ "Family Guy , "" ⟩ . Furthermore, "Family Guy"^^ rdf:text is not a valid literal of rdf:text because its lexical value does not containabove definition, the character @subset of the value space of owl:realPlus between -1 and 1 contains both +0 and -0.

Facet Space. The facet space of the rdf:texteach numeric datatype DT is shown in Table 6.5.

Table 6.5. The Facet Space of the rdf:texta Numeric Datatype DT
Pair Facet Value
⟨ xsd:minLength lt ⟩xsd:minInclusive V
where ltV is a numeric literal whosefrom the value is a nonnegative integerspace of owl:realPlus 		the set of all pairs ⟨ a , b ⟩ ∈ (rdf:text)numbers x (DT)DT such that the length of a is at least (lt) LT ⟨ xsd:maxLength lt ⟩x = V or x > V
xsd:maxInclusive V
where ltV is a numeric literal whosefrom the value is a nonnegative integerspace of owl:realPlus 		the set of all pairs ⟨ a , b ⟩ ∈ (rdf:text)numbers x (DT)DT such that the length of a is at most (lt) LT ⟨ xsd:length lt ⟩x = V or x < V
xsd:minExclusive V
where ltV is a numeric literal whosefrom the value is a nonnegative integerspace of owl:realPlus 		the set of all pairs ⟨ a , b ⟩ ∈ (rdf:text)numbers x (DT)DT such that the length of a is exactly (lt) LT ⟨ xsd:pattern lt ⟩x > V
xsd:maxExclusive V
where ltV is an xsd:string literal specifying a regular expression withfrom the syntax as in Section Fvalue space of XML Schema Datatypes [ XML Schema Datatypes ]owl:realPlus 		the set of all pairs ⟨ a , b ⟩ ∈ (rdf:text)numbers x (DT)DT in which a matches the regular expression (lt) LT ⟨ rdf:langPattern lt ⟩ where lt is an xsd:string literal specifying a regular expressionsuch that x < V

Relationship with the syntax as in Section F ofXML Schema Datatypes [ XML Schema Datatypes ] the set of all pairs ⟨ a , b ⟩ ∈ (rdf:text) DT in which b matches the regular expression (lt) LT Editor's Note: Depending on the outcome of the discussions with the RIF Working Group, the definition of the facet space of rdf:text might be moved to [ RDF:TEXT ]Schema. Numeric datatypes in OWL 2 differ from the final versionnumeric datatypes of this document. 4.2.2 Strings without a Language Tag As recommended in [ RDF:TEXT ], the followingXML Schema Datatypes[XML Schema Datatypes] are interpretedin the following aspects:

In other respects, the numeric datatypes of OWL 2 agree with the definitions of XML Schema Datatypes [XML Schema Datatypes].

Facet Space. Each datatype DT from4.2 Strings

OWL 2 uses the above list supportsrdf:text datatype for the constraining facets xsd:minLength , xsd:maxLength , xsd:length , and xsd:pattern .representation of strings in a particular language. The facet valuedefinitions of each pair for DT isthe same as in Table 6, withvalue space, the difference thatlexical space, the result is a subset of (DT) DT instead of (rdf:text) DT . Relationship with XML Schema. Unlike OWL 2,facet space, and the datatypes listed in this sectionnecessary mappings are interpreted in XML Schema as simple strings rather than pairs. This departure from XML Schema has been introducedgiven in [RDF:TEXT].

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

As recommended in order to make[RDF:TEXT], the value spaces of these datatypes are subsets of the value space of rdf:text . Since the language part of each pair is empty, the value spaces of these datatypes in OWL 2 are isomorphic with the respective value spaces in XML Schema. Hence, this difference in the value spaces does not affect the logical consequences of OWL 2 ontologies that do not use; please refer to [RDF:TEXT .] for a precise definition.

4.3 Boolean Values

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

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

Literals.Lexical Space. The xsd:boolean datatype supports the following literals: "true"^^ xsd:booleanlexical values:

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

4.4 Binary Data

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

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

Literals. DatatypesLexical Spaces. The lexical values of the xsd:hexBinary and xsd:base64Binary allow for literalsdatatypes are strings of the form "abc"^^ xsd:hexBinary and "abc"^^ xsd:base64Binary , where"abc", whose structure is a string aspecified in Section 3.2.15Sections 3.3.16 and 3.2.163.3.17 of XML Schema Datatypes [XML Schema Datatypes], respectively. Such literalsThe lexical values are mapped to data values as specified in XML Schema Datatypes [XML Schema Datatypes].

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

Table 7.6. The Facet Space of the xsd:hexBinary and xsd:base64Binary Datatypes
Pair Facet Value
⟨xsd:minLength lt ⟩V
where lt is a numeric literal whose valueV is a nonnegative integer 		the set of finite sequences of octets of length at least (lt) LT ⟨V
xsd:maxLength lt ⟩V
where lt is a numeric literal whose valueV is a nonnegative integer 		the set of finite sequences of octets of length at most (lt) LT ⟨V
xsd:length lt ⟩V
where lt is a numeric literal whose valueV is a nonnegative integer 		the set of finite sequences of octets of length exactly (lt) LTV

4.5 URIs

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

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

Literals.Lexical Space. The xsd:anyURI datatype supports literalslexical values of the form "abc"^^xsd:anyURI where "abc" is a string asdatatype and their mapping to data values are defined in Section 3.2.173.3.18 of XML Schema Datatypes [XML Schema Datatypes].

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

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

Table 8.7. The Facet Space of the xsd:anyURI Datatype
Pair Facet Value
⟨xsd:minLength lt ⟩V
where lt is a numeric literal whose valueV is a nonnegative integer 		the set of URIs U ∈(xsd:anyURI)DT such that the length of the string representation of U is at least (lt) LT ⟨V
xsd:maxLength lt ⟩V
where lt is a numeric literal whose valueV is a nonnegative integer 		the set of URIs U ∈(xsd:anyURI)DT such that the length of the string representation of U is at most (lt) LT & lang;V
xsd:length lt ⟩V
where lt is a numeric literal whose valueV is a nonnegative integer 		the set of URIs U ∈(xsd:anyURI)DT such that the length of the string representation of U is exactly (lt) LT ⟨ xsd:pattern lt ⟩ where lt is an xsd:string whose valueV
xsd:pattern V
where V is a string regular expression
with the syntax as in Section F of XML Schema Datatypes [XML Schema Datatypes] 		the set of URIs U ∈(xsd:anyURI)DT whose string representation matches the regular expression (lt) LTV

4.6 Time Instants

OWL 2 provides the owl:dateTime datatype for the representation of time instants. This datatype is based on, but is notequivalent to the xsd:dateTime datatype of XML Schema Datatypes [XML Schema Datatypes ]. Editor's] with a required timezone.

Feature At Risk #3: owl:dateTime name

Note: The resolution of OWL WG ISSUE-138This feature is "at risk" and may affectbe removed from this specification based on feedback. Please send feedback to public-owl-comments@w3.org.

The URIname owl:dateTime is currently a placeholder. XML Schema 1.1 Working Group will introduce a datatype for owl:dateTime.date-time with required timezone. Once this is done, owl:dateTime will be changed to whatever name XML Schema chooses. If the schedule of the XML Schema 1.1 Working Group slips the OWL 2 Working Group will consider possible alternatives.

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

Literals.Lexical Space. The owl:dateTime datatype supports literals of the form "rep"^^ owl:dateTime where "rep" is a stringlexical values defined by the following grammar (whitespace within the grammar is irrelevantMUST be ignored and MUST NOT be included in the lexical values of owl:dateTimte, and single quitesquotes are used to introduce terminal symbols):

year '-' month '-' date 'T' hour ':' minute ':' second timezone

The components of the this string are as follows:

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

dataValue(year, month, day, hour, minutes, seconds, timezone) =
   31536000 ×(year-1) +        *# convert all previous years to seconds
*    86400 ×( (year-1) div 400 - (year-1) div 100 + (year-1) div 4) +        *# adjust for leap years
*    86400 ×Summ < month daysInMonth(year, m) +        *# add the duration of each month
*    86400 ×(day-1) +        *# add the duration of the previous days
*    3600 ×hour + 60 ×(minutes - timezone) + seconds        *# add the current time


*daysInMonth(y, m) =
   28    if m = 2 and [ (y mod 4 ≠0) or (y mod 100 = 0 and y mod 400 ≠0) ]
   29    if m = 2 and [ (y mod 400 = 0) or (y mod 4 = 0 and y mod 100 ≠0) ]
   30    if m ∈{ 4, 6, 9, 11 }
   31    if m ∈{ 1, 3, 5, 7, 8, 10, 12 }

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

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

Table 9.8. The Facet Space of the owl:dateTime Datatype
Pair Facet Value
⟨xsd:minInclusive lt ⟩V
where ltV is anfrom the value space of owl:dateTime 		literalthe set of all time instants x ∈(owl:dateTime)DT such that x = (lt) LTV or x > (lt) LT ⟨V
xsd:maxInclusive lt ⟩V
where ltV is anfrom the value space of owl:dateTime 		literalthe set of all time instants x ∈(owl:dateTime)DT such that x = (lt) LTV or x < (lt) LT ⟨V
xsd:minExclusive lt ⟩V
where ltV is anfrom the value space of owl:dateTime 		literalthe set of all time instants x ∈ (owl:dateTime) DT such that x > (lt) LT ⟨ xsd:maxExclusive lt ⟩ where ltset of all time instants x (owl:dateTime)DT such that x > V
xsd:maxExclusive V
where V is from the value space of owl:dateTime 		the set of all time instants x (owl:dateTime)DT such that x < V

4.7 XML Literals

OWL 2 uses the rdf:XMLLiteral datatype for the representation of XML content in OWL 2 ontologies. The definitions of the value space, the lexical space, and the mapping from the lexical to the value space are given in Section 5.1 of the RDF specification [RDF]. The rdf:XMLLiteral datatype supports no constraining facets.

Feature At Risk #4: rdf:XMLLiteral support

Note: This feature is an owl:dateTime literal"at risk" and may be removed from this specification based on feedback. Please send feedback to public-owl-comments@w3.org.

This datatype might be removed from OWL 2 if the setusers and implementors of all time instants x ∈ (owl:dateTime) DT such that x < (lt) LTOWL 2 do not express support to the datatype.

5 Entities and Literals

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

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

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

5.1 Classes

Classes can be understood as sets of individuals.

Class  :=:= URI

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

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:ChildEach child is a subclass of a:Person .person.

5.2 Datatypes

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

Datatype  :=:= URI

The datatype xsd:integer denotes the set of all integers. It can be used in theaxioms such as the following one:

PropertyRange( a:hasAge xsd:integer ) The range of the a:hasAge property is xsd:integer.

5.3 Object Properties

Object properties connect pairs of individuals.

ObjectProperty  :=:= URI

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

The object property a:parentOf can be used to represent the parenthood relationship between individuals. It can be used in theaxioms such as the following one:

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

5.4 Data Properties

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

DataProperty  :=:= URI

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

The data property a:namea:hasName can be used to associate a name with each person. It can be used in theaxioms such as the following one:

PropertyAssertion( a:namea:hasName a:Peter "Peter Griffin" ) The a:name of a:PeterPeter's name is "Peter Griffin".Griffin".

5.5 Annotation Properties

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

AnnotationProperty  :=:= URI

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

The annotation property rdfs:comment can be used to associate acomment with ontology entities. It can be used in axioms such asprovided by the following one (where theannotation is represented usingassertion axiom can, for example, be used by an OWL 2 tool to display additional information about the abbreviated syntax): EntityAnnotation( NamedIndividual (URI a:Peter.

AnnotationAssertion( rdfs:comment a:Peter )     Comment("The father of the Griffin family from Quahog." ) )This axiom provides a comment for the individualURI a:Peter.

5.6 Individuals

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

Individual  :=:= NamedIndividual | AnonymousIndividual

5.6.1 Named Individuals

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

NamedIndividual  :=:= URI

The individual a:Peter can be used to represent a particular person. It can be used in axioms such as the following one:

ClassAssertion( a:Person a:Peter ) a:PeterPeter is an instance of a:Person .a person.

5.6.2 Anonymous Individuals

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

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:PeterPeter lives at some address, represented using the anonymous individual _:1 .(unknown) address.
PropertyAssertion( a:city _:1 a:Quahog ) The object represented by the anonymous individual _:1This unknown address is related to individual a:Quahog byin the property a:city .city of Quahog and...
PropertyAssertion( a:state _:1 a:RI ) The object represented by the anonymous individual _:1 related to individual a:RI (representing...in the state of Rhode Island) by the property a:state .Island.

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

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 replacedin O1 is replaced with a fresh anonymous individual, or this must beis done for _:a5 in O2.

5.7 Literals

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

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

lexicalValue  := quotedStringLiteral:= typedLiteral | abbreviatedXSDStringLiteral | abbreviatedRDFTextLiteral
typedLiteral  :=:= lexicalValue '^^' Datatype
lexicalValue:= quotedString
abbreviatedXSDStringLiteral  :=:= quotedString
abbreviatedRDFTextLiteral  :=:= quotedString '@' languageTag

Literal  := typedLiteral | abbreviatedXSDStringLiteral | abbreviatedRDFTextLiteral "1"^^xsd:integer"1"^^xsd:integer is a literal that represents the integer 1.

"Family Guy" is an abbreviation for "Family Guy"^^xsd:string —a literal with the lexical value "Family Guy" and typethe datatype xsd:string.

"Padre de familia"@es is an abbreviation for the literal "Padre de familia@es"^^rdf:text —a literal denoting a pair consisting of the string "Padre de familia" and the language tag es denoting the Spanish language.

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

Even through literals "1"^^xsd:integer"1"^^xsd:integer and "+1"^^xsd:integer"+1"^^xsd:integer are interpreted as the integer 1, these two literals are not structurally equivalent because their lexical values are not the same. Similarly, "1"^^xsd:integersame. Similarly, "1"^^xsd:integer and "1"^^xsd:positiveInteger are not structurally equivalent because their datatypes are not the same.

5.8 Entity Declarations and Typing

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

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 "1"^^xsd:positiveInteger are not structurally equivalent because their datatypes are notit states that the same. 5.8 ReferringURI is used as a class. An ontology editor might use declarations to Entities in Functional-Style Syntax In several placesimplement functions such as "Add New Class".

In the functional-style syntax, one needs to unambiguously referOWL 2, declarations are a type of axiom; thus, to declare an entity. Since a URIentity in an ontology, one can be used for several entities (of different types) at once, a URI by itself doessimply include the appropriate axiom into the ontology. These axioms are nonlogical in the sense that they do not unambiguously identifyaffect the direct semantics of an entity.OWL 2 ontology [OWL 2 Direct Semantics]. The typestructure of a URIentity declarations is shown in such cases disambiguated explicitly.Figure 3.

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

Declaration:= 'Declaration' '(' axiomAnnotations Entity ')'
Entity  :=    :=
'Class' '(' Class ')' |
   'Datatype' '(' Datatype ')' |
   'ObjectProperty' '(' ObjectProperty ')' |
   'DataProperty' '(' DataProperty ')' |
   'AnnotationProperty' '(' AnnotationProperty ')' |
   'NamedIndividual' '(' NamedIndividual ')'

5.9 Entity DeclarationsThe following axioms state that the URI a:Person is used as a class and Typing Each entity uthat the URI a:Peter is used inas an individual.

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

Declarations for the built-in entities of OWL 2 ontology O can, and sometimes even must, be declared2, listed in O ; roughly speaking, this means that the axiom closureTable 9, are implicitly present in every OWL 2 ontology.

Table 9. Declarations of O must contain an appropriate declarationBuilt-In Entities
Declaration( Class( owl:Thing ) )
Declaration( Class( owl:Nothing ) )
Declaration( ObjectProperty( owl:topObjectProperty ) )
Declaration( ObjectProperty( owl:bottomObjectProperty ) )
Declaration( DataProperty( owl:topDataProperty ) )
Declaration( DataProperty( owl:bottomDataProperty ) )
Declaration( Datatype( rdfs:Literal ) )
Declaration( Datatype( U ) ) for each URI U .of a declarationdatatype in the datatype map (see Section 4)
Declaration( AnnotationProperty( U ) ) for each URI U of a built-in annotation property listed in O serves two purposes:Section 5.5

5.8.1 Typing Constraints

A declaration says that u exists — that is, it says thatURI U is part of the vocabularydeclared to be of O . A declaration associates with u an entitytype — that is, it says whether u is a class, datatype, object property, data property, annotation property, an individual, or a combination thereof.T in an OWL 2 ontology might containO if a declaration axiom of type T for the URI a:Person and state that this URIU is a class. Such a declaration states that a:Person existscontained in the ontology and it determines the typeaxiom closure of O or in the URI as being a class. An ontology editor might useset of built-in declarations to implement functions such as "Add New Class".listed in OWL 2, declarations areTable 9. An ontology O can declare a type of axiom; thus,URI U to be of more than one type, and it must declare an entityU in an ontology, one can simply include the appropriate axiom intocertain cases; the ontology. These axiomsrules governing declarations are nonlogical in the sense that they docalled typing constraints and are listed below. If O does not affect the model-theoretic meaning of an ontology [ OWL 2 Direct Semantics ]. Declarations have been defined assatisfy these typing constraints, it is syntactically invalid.

The typing constraints thus ensure that the sets of URIs used as object, data, and annotation properties in O are disjoint and that, similarly, the sets of URIs used as 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.

A URI U is declared tocan be of type T inused as an OWL 2 ontologyindividual in O even if a declaration axiom of type T forU is containednot declared as an individual in the axiom closure ofO or.

Declarations are often omitted in the setexamples in this document in cases where types of built-inentities are intuitively clear.

5.8.2 Declaration Consistency

Although declarations listed in Table 10. An ontology Oare optional for the most part, they can declare a URI u tobe of more than one type, and it must declare uused to catch obvious errors in certain cases;ontologies.

The rules governing declarations are known as typing constraints and are listed below. If O does not satisfy these typing constraints, it is syntactically invalid. Property typing constraints: If an object property with a URI u occursfollowing ontology erroneously refers to the individual a:Petre instead of the individual a:Peter.

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

There is no way of telling whether a:Petre was used by mistake. If, in some axiomcontrast, all individuals in O , then O MUST declare uan ontology were by convention required to be an object property. If a data property withdeclared, this error could be caught by a URI u occurs in some axiom in O , thensimple tool.

An ontology O MUST declare uis said to be a data property.have consistent declarations if an annotation property with aeach URI U occursoccurring in somethe axiom in O , thenclosure of O MUST declare u to bein position of an annotation property.entity with a URI u MUST NOT betype T is declared in O as being of more than onehaving type of property; that is, u MUSTT. OWL 2 ontologies are not be declared in O to be both object and data, object and annotation, or data and annotation property. Class/datatype typing constraints: If a class with a URI u occurs in some axiom in O , then O MUST declare urequired to have consistent declarations: an ontology MAY be a class.used even if a datatype with a URI u occurs in some axiom in O , then O MUST declare u to be a datatype. A URI u MUSTits declarations are not be declared inconsistent.

The axiom closure of Oontology from the previous example fails this check: a:Petre is used as an individual but the ontology does not declare a:Petre to be both a class and a datatype. A declarationan individual, and similarly for a URI u MUST NOT violatea:Person. In contrast, the constraints onfollowing ontology satisfies this condition.

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

5.8.3 Canonical Parsing

Many OWL 2 tools need to support ontology parsing the usageprocess of reserved vocabulary listedconverting an ontology document written in a particular syntax into appropriate instances of the previous sections. The typing constraints thus ensure thatclasses from the setsstructural specification of object, data, and annotation propertiesOWL 2. In O are disjoint and that, similarly,order to be able to instantiate the sets ofappropriate classes and datatypes in O are disjoint as well. These constraints are used for disambiguatingfrom the types ofstructural specification, the ontology parser sometimes needs to know which URIs when reading ontologies from external transfer syntaxes. All other declarationsare optional. A URI u can beused in the ontology as entities of which type. This typing information is extracted from declarations.

An individualontology parser for the ontology documents written in O even if ufunctional-style syntax might encounter the following axiom:

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

From this axiom alone, it is not declared asclear whether a:parentOf is an individualobject or a data property, and whether a:Child is a class or a datatype. In O .order to disambiguate the types of these URIs, the parser needs to look at the declarations are often omittedthe ontology document being parsed, as well as into the directly or indirectly imported ontology documents.

In OWL 2 there is no requirement for a declaration of an entity to physically precede the examples in this documententity's usage in cases where types of entities are intuitively clear. 5.9.2 Declaration Consistency Althoughontology documents; furthermore, declarations are optionalfor the most part, theyentities can be usedplaced into imported ontology documents and imports are allowed to catch obvious errorsbe cyclic. In ontologies. The following ontology erroneously refersorder to precisely define the individual a:Petre insteadresult of ontology parsing, this specification defines the individual a:Peter . Ontology(< http://www.my.domain.com/example >     ClassAssertion( a:Person a:Petre ) ) There is no waynotion of telling whether a:Petre was used by mistake. If, in contrast, all individuals incanonical parsing. An ontology were by convention required to be declared, this error could be caught byOWL 2 parser MAY implement parsing in any way it chooses, as long as it produces a simple tool. An ontology Oresult that is saidstructurally equivalent to have consistent declarations if each URI u occurring inthe axiom closureresult of O in positioncanonical parsing.

The result of canonical parsing of an entity with a type Tontology document D is declared inthe ontology O as having type T . This check applies also toobtained by the entities used in annotations; that is,following process. If any of these entitiessteps cannot be completed for some reason, then D MUST be properly declaredrejected as well for an ontologysyntactically invalid.

It is not clear whether a:parentOf is an object or a data property,important to understand that canonical parsing merely defines the result of the parsing process, and whether a:Child is a class orthat a datatype."smart" implementation of OWL 2 MAY optimize this process in numerous ways. In order to disambiguateenable efficient parsing, OWL 2 implementations are encouraged to write ontologies into documents by placing all URI declarations before the types ofaxioms that use these URIs, theURIs; however, this is not required for conformance.

A "smart" parser needs to look at the declarations infor the axiom closurefunctional-style syntax of OWL 2 can parse the ontology being parsed.in OWL 2 there is no requirement fora declaration of an entity to physically precedesingle pass when the entity's usage in ontology documents; furthermore,declarations for entities can be locatedthe URIs are placed in the text of O physically before the URIs are used. Similarly, a "smart" parser can optimize the handling of imported ontologies and imports are allowed to be cyclic.in order to precisely definecases when the result of ontology parsing, this specification definesimport relation between the notionontologies is acyclic.

In some cases, it is possible to infer the existence of canonical parsing .missing declarations. An OWL 2 parserimplementation MAY implement parsing in any way it chooses, as long as it produces a result thatrepair such ontologies by adding missing declarations. The precise repair process is structurally equivalentnot covered by this specification. If repair is applied, the resulting ontology MUST satisfy the typing constraints from Section 5.8.1; that is, the missing declarations MUST actually be added to the result of canonical parsing.ontology.

Consider an ontology containing the result of canonical parsing offollowing axioms:

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

The only way for the text of anontology Oto make sense is if a:parentOf were declared to be an object property. Hence, the set of axioms obtainedontology can be repaired by adding the following process: The text of O is analyzed in orderdeclaration to extractthe set of URIs Imp(O) of the ontologies imported in O andaxioms:

Declaration( ObjectProperty( a:parentOf ) )

5.9 Metamodeling

According to the set of declarations Decl(O) explicitly present in O . For each URI utyping constraints from the set Imp(O) , the text of the ontology pointed at by u is located as specified inSection 3.45.8.1, and the previous step is repeated recursively. Let AllDecl(O)a URI U can be the set of all declarationsused in an OWL 2 ontology to refer to more than one type of O , defined as the unionentity. Such usage of the set Decl(O) , the sets Decl(O') for each ontology O' thatU is (directly or indirectly) imported into Ooften called metamodeling, because it can be used to state facts about classes and the set of declarations listed in Table 10. The set AllDecl(O) is next checked for typing consistency as specifiedproperties themselves. In Section 5.9.1 . If any ofsuch cases, the constraints is invalidated,entities that share the ontology O is rejectedsame URI U should be understood as syntactically incorrect. The text of O is analyzed again and the axioms of O are converted into instancesdifferent "views" of the structural specification according tosame underlying notion identified by the rules ofURI U.

Consider the respective syntax. Declarationsfollowing ontology.

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

In AllDecl(O) are used to correctly disambiguatethe first axiom, the URI references. If Oa:Dog is writtenused as a class, while in the functional-style syntax, these declarations aresecond axiom, it is used to disambiguateas an individual; thus, the productionsclass a:Species acts as a metaclass for the class , Datatype , ObjectProperty , DataProperty , AnnotationProperty , and NamedIndividuala:Dog. It is important to understand that canonical parsing merely defines the result ofThe parsing process,individual a:Dog and that a "smart" implementationthe class a:Dog should be understood as two "views" of one and the same URI a:Dog. Under the OWL 2 MAY optimize this process in numerous ways. In order to enable efficient parsing,Direct Semantics [OWL 2 implementationsDirect Semantics], these two views are encouraged to write ontologies into documents by placing all URI declarations beforeinterpreted independently: the axioms that use these URIs; however, thisclass view of a:Species is not required for conformance.interpreted as a "smart" OWL 2 parser can parseunary predicate, while the ontology inindividual view of a:Species is interpreted as a single pass when the declarations for the URIs are located inconstant.

Both metamodeling and annotations provide means to associate additional information with classes and properties. The text of O physically beforethe URIs are used. Similarly, a "smart" OWL 2 parserfollowing rule-of-the-thumb can optimizebe used to determine when to use which construct:

Consider an ontology containingthe following axioms: Declaration( Class( a:Child )ontology.

ClassAssertion( a:Dog a:Brian ) SubClassOf ( a:Father SomeValuesFrom( a:parentOf a:ChildBrian is a dog.
ClassAssertion( a:PetAnimals a:Dog ) Dogs are pet animals.
AnnotationAssertion( a:addedBy a:Dog "Seth MacFarlane" ) The only way forURI a:Dog has been added to the ontology to make senseby Seth MacFarlane.

The facts that Brian is if a:parentOf were declared to be an object property. Hence,a dog and that dogs are pet animals are statements about the domain being modeled. Therefore, these facts are represented in the above ontology can be repaired by addingvia metamodeling. In contrast, the following declarationinformation about who added the URI a:Dog to the setontology does not describe the actual domain being modeled, but might be interesting from a management point of axioms: Declaration( ObjectProperty( a:parentOf ) )view. Therefore, this information is represented using an annotation.

6 Property Expressions

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

6.1 Object Property Expressions

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

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 in class expressions and axioms.

ObjectPropertyExpression  :=:= ObjectProperty | InverseObjectProperty

6.1.1 Inverse Object Properties

An inverse object property expression InverseOf( P ) connects an individual I1 with I2 if and only if the object property P connects I2 with I1.

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

Consider the ontology consisting of the following assertion.

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

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

6.2 Data Property Expressions

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

Data Property Expressions
Figure 5. Data Property Expressions

DataPropertyExpression  :=:= DataProperty

7 Data Ranges

Editor's Note: OWL WG ISSUE-127 is related to n-ary data ranges and might impact this section.Datatypes, such as strings or integers, can be used to express data ranges —sets of tuples of literals. Each data range is associated with a positive arity, which determines the size of the tuples in the data range. All datatypes have arity one. This specification currently does not define data ranges of arity more than one; however, by allowing for n-aryn-ary data ranges, the syntax of OWL 2 provides a "hook" for implementationsallowing complex data ranges involving, for example,implementations to introduce extensions such as comparisons and arithmetic.

Data ranges can be used in restrictions on data properties, as discussed in Sections 8.4 and 8.5. The structure of data ranges in OWL 2 is shown in Figure 6. The simplest data ranges are datatypes. The DataIntersectionOf, DataUnionOf, and DataComplementOf data range consists of all literals that are not inranges provide for the specifiedstandard set-theoretic operations on data range.ranges; in logical languages these are usually called conjunction, disjunction, and negation, respectively. The nominal DataOneOf data range consists exactly the specified set of literals. Finally, the DatatypeRestriction data ranges are obtained by restricting the value space of a datatype by a constraining facet.

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

DataRange  :=    :=
Datatype |
   DataIntersectionOf |
DataUnionOf |
DataComplementOf |
   DataOneOf |
   DatatypeRestriction

7.1 Intersection of Data Ranges

An intersection data range IntersectionOf( DR1 ... DRn ) contains all data values that are contained in the value space of all data ranges DRi for 1 i n. All data ranges DRi must be of the same arity.

DataIntersectionOf:= 'IntersectionOf' '(' DataRange DataRange { DataRange } ')'

The data range IntersectionOf( xsd:nonNegativeInteger xsd:nonPositiveInteger ) contains exactly the integer 0.

7.2 Union of Data Ranges

A union data range UnionOf( DR1 ... DRn ) contains all data values that are contained in the value space of at least one all data range DRi for 1 i n. All data ranges DRi must be of the same arity.

DataUnionOf:= 'UnionOf' '(' DataRange DataRange { DataRange } ')'

The data range UnionOf( xsd:string xsd:integer ) contains all strings and all integers.

7.3 Complement of Data Ranges

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

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

The complement data range ComplementOf( xsd:positiveInteger ) consists of literals 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).

7.27.4 Enumerated Data Ranges

An enumerated data range OneOf( lt1 ... ltn ) contains exactly the explicitly specified literals lti with 1 ≤i ≤n.

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

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

7.37.5 Datatype Restrictions

A datatype restriction DatatypeRestriction( DT F1 lt1 ... Fn ltn ) consists of a unary datatype DT and n pairs ⟨Fi ,lti ⟩. Let vi be the setdata values of allowed constraining facets is determined bythe corresponding literals lti. This datatype andrestriction is syntactically valid if Fi vi is in the facet space of DT in the datatype map (see |SectionSection 4 ), and). The resulting unary data range denotes the subset ofis obtained by restricting the value space of DT restrictedaccording to the semantics of all ⟨Fi , ltvi ⟩(multiple pairs are interpreted conjunctively).

constrainingFacet  := URI restrictionValue  := LiteralDatatypeRestriction  :=:= 'DatatypeRestriction' '(' Datatype constrainingFacet restrictionValue { constrainingFacet restrictionValue } ')'
constrainingFacet:= URI
restrictionValue:= Literal

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

8 Class Expressions

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

A class expression can be used to represent the set of "people that have at least one child". If an ontology additionally 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.

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

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

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

8.1 Propositional Connectives and Nominals

OWL 2 provides for nominals and all standard Boolean connectives, as shown in Figure 7. The ObjectIntersectionOf, ObjectUnionOf, and ObjectComplementOf class expressions provide for the standard set-theoretic operations;operations on class expressions; 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 preciselycontains exactly the specified individuals.

Propositional Connectives and Nominals
Figure 7. Propositional Connectives and Nominals

8.1.1 Intersection of Class Expressions

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:BrianBrian is a dog.
ClassAssertion( a:CanTalk a:Brian ) a:BrianBrian 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.

8.1.2 Union of Class Expressions

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:PeterPeter is a man.
ClassAssertion( a:Woman a:Lois ) a:LoisLois is a woman.

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

8.1.3 Complement of Class Expressions

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 objectNothing can be both a man and a woman.
ClassAssertion( a:Woman a:Lois ) a:LoisLois 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,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 has open-world semantics, so negation in OWL 2 is the same as in classical (first-order) logic. To understand open-world semantics, consider the ontology consisting of the following assertion.

ClassAssertion( a:Dog a:Brian ) a:BrianBrian 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 is actually true but it has not been included into the ontology.

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 concludelead to a conclusion 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.

8.1.4 Nominals

A nominal class expression OneOf( a1 ... an ) contains exactly the individuals ai with 1 ≤i ≤n.

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

Consider the ontology consisting of the following axioms.

EquivalentClasses( a:GriffinFamilyMember
   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 individualsQuagmire, Peter, Lois, Stewie, Meg, Chris, and Brian are all different from each other.

The class a:GriffinFamilyMember now contains exactly the named fivesix explicitly listed individuals. Since we also know that a:Quagmire is different from these six individuals, itthis individual is classified as an instance of the class expression ComplementOf( a:GriffinFamilyMember ). The last axiom is necessary to derive this conclusion; without it, the open-world 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 semantics affects nominals, consider the ontology consisting of the following axioms.

ClassAssertion( a:GriffinFamilyMember a:Peter ) a:PeterPeter is a member of the Griffin Family.
ClassAssertion( a:GriffinFamilyMember a:Lois ) a:LoisLois is a member of the Griffin Family.
ClassAssertion( a:GriffinFamilyMember a:Stewie ) a:StewieStewie is a member of the Griffin Family.
ClassAssertion( a:GriffinFamilyMember a:Meg ) a:MegMeg is a member of the Griffin Family.
ClassAssertion( a:GriffinFamilyMember a:Chris ) a:ChrisChris is a member of the Griffin Family.
ClassAssertion( a:GriffinFamilyMember a:Brian ) a:BrianBrian is a member of the Griffin Family.

The class a:GriffinFamilyMember 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:GriffinFamilyMember is not closed: the semantics of OWL 2 assumes that information about a potential instance of a:GriffinFamilyMember may be missing. Therefore, a:Quagmire is now not classified as an instance of the class expression ComplementOf( a:GriffinFamilyMember ), and this does not change even if we add the axiom stating that all of these six individuals are different from each other.

8.2 Object Property Restrictions

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

Restricting Object Property Expressions
Figure 8. Restricting Object Property Expressions

8.2.1 Existential Quantification

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

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

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:PeterPeter is the father of a:Stewie .Stewie.
ClassAssertion( a:Man a:Stewie ) a:StewieStewie 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.

8.2.2 Universal Quantification

A universal class expression AllValuesFrom( OPE CE ) consists of an object property expression OPE and a class expression CE, and it contains all those individuals that are connected by OPE only to individuals that are instances of CE. Provided that OPE is simple according to the definition in Section 11, such a class expression can be seen as a syntactic shortcut for the class expression MaxCardinality( 0 OPE ComplementOf( 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 asBrian is a pet.pet of Peter.
ClassAssertion( a:Dog a:Brian ) a:BrianBrian is a dog.
ClassAssertion( MaxCardinality( 1 a:hasPet ) a:Peter ) a:PeterPeter has at most one thing as apet.

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 connect a:Peter by a:hasPet to an individual different from a:Brian 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 semantics 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 ).

8.2.3 Individual Value RestrictionsRestriction

A has-value class expression HasValue( OPE a ) consists of an object property expression OPE and an individual a, and it contains all those individuals that are connected by OPE to a. Each such class expression is equivalent tocan be seen as a syntactic shortcut for the existential restrictionclass expression SomeValuesFrom( OPE OneOf( a ) ).

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

Consider the ontology consisting of the following axiom.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:PeterPeter is the father of a:Stewie .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.

8.2.4 Self-Restriction

A self-restriction ExistsSelf( PEHasSelf( OPE ) consists of aan object property expression PEOPE, and it contains all those individuals that are connected by PEOPE to themselves.

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

Consider the ontology consisting of the following axiom.

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

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

8.3 Object Property Cardinality Restrictions

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

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

8.3.1 Minimum Cardinality

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

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

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:PeterPeter is the father of a:Stewie .Stewie.
ClassAssertion( a:Man a:Stewie ) a:StewieStewie is a man.
PropertyAssertion( a:fatherOf a:Peter a:Chris ) a:PeterPeter is the father of a:Chris .Chris.
ClassAssertion( a:Man a:Chris ) a:ChrisChris is a man.
DifferentIndividuals( a:Chris a:Stewie ) a:ChrisChris and a:StewieStewie 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 the open-world semantics, 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.

8.3.2 Maximum Cardinality

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

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 asBrian is a pet.pet of Peter.
ClassAssertion( MaxCardinality( 1 a:hasPet ) a:Peter ) a:PeterPeter 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 is 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 semantics. 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:MegMeg is a daughter of a:Peter .Peter.
PropertyAssertion( a:hasDaughter a:Peter a:Megan ) a:MeganMegan is a daughter of a:Peter .Peter.
ClassAssertion( MaxCardinality( 1 a:hasDaughter ) a:Peter ) a:PeterPeter 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. This ontology, however, is not inconsistent because the semantics of OWL 2 does not have unique name assumption —that is, it does not assume distinct individuals to be necessarily different. For exmaple,example, 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 differentdistinct individual, one concludes thata:Meg is the same asand a:Megan .must be the same. 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 ,Peter, Meg, and a:MeganMegan are all different from each other.

8.3.3 Exact Cardinality

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

IntersectionOf( MinCardinality( n OPE CE ) MaxCardinality( 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 asBrian is a pet.pet of Peter.
ClassAssertion( a:Dog a:Brian ) a:BrianBrian is a dog.
ClassAssertion(
   AllValuesFrom( a:hasPet
      UnionOf(
         OneOf( a:Brian )
         ComplementOf( a:Dog )
       )
   )
   a:Peter
) 		Each pet of a:PeterPeter is either a:BrianBrian or it is not a dog.

The exact cardinality expression ExactCardinality( 1 a:hasPet a:Dog ) contains those individuals that are connected by a:hasPet to exactly one instance of a:Dog. The example ontology says that a:Peter is connected to a: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 ).

8.4 Data Property Restrictions

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

Restricting Data Property Expressions
Editor's Note: OWL WG ISSUE-127 is related to n-ary data ranges and might impact this section.Figure 10. Restricting Data Property Expressions

8.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 it contains all those individuals that are connected by DPEi to literals lti, 1 ≤i ≤n, such that the tuple ⟨lt1, ..., ltn ⟩is in DR. A class expression of the form SomeValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expression MinCardinality( 1 DPE DR ).

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.Meg is seventeen years old.

The existential class expression SomeValuesFrom( a:hasAge DatatypeRestriction( xsd:integer maxExclusivexsd:maxExclusive "20"^^xsd:integer ) ) contains all individuals 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.

8.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 it contains all those individuals that are connected by DPEi only to literals lti, 1 ≤i ≤n, such that each tuple ⟨lt1, ..., ltn ⟩is in DR. A class expression of the form AllValuesFrom( DPE DR ) can be seen as a syntactic shortcut for the class expression MaxCardinality( 0 DPE ComplementOf( DR ) ).

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 xsd:integer ) to identify those individuals 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, and the second axiom ensures that _:a1 is not connected by a:zipCode to other literals; therefore, _:a1 is classified as an instance of AllValuesFrom( a:hasZIP 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 semantics of OWL 2. Without this axiom, the ontology is incomplete in the sense that it may not list all literals that _:a1 is connected to by a:hasZIP; hence, without this axiom _:a1 would not be classified as an instance of AllValuesFrom( a:hasZIP xsd:integer ).

8.4.3 Literal ValuesValue Restriction

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

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

Consider the ontology consisting of the following axiom.

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

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.

8.5 Data Property Cardinality Restrictions

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

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

8.5.1 Minimum Cardinality

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

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

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasName a:Meg "Meg""Meg Griffin" ) a:MegMeg's name is called "Meg"."Meg Griffin".
PropertyAssertion( a:hasName a:Meg "Megan""Megan Griffin" ) a:MegMeg's name is called "Megan"."Megan Griffin".

The minimum cardinality expression MinCardinality( 2 a:hasName ) contains those individuals that are connected by a:hasName to at least two different literals. The xsd:string datatypes interprets different string literals as being distinct, so "Meg""Meg Griffin" and "Megan""Megan Griffin" are different; thus, the individual a:Meg is classified as an instance of the class expression MinCardinality( 2 a:hasName ).

8.5.2 Maximum Cardinality

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

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 literals. Since the ontology axiom restricts a:hasName to be functional, all individuals in the ontology are instances of this class expression.

8.5.3 Exact Cardinality

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

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

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasName a:Brian "Brian""Brian Griffin" ) a:BrianBrian's name is called "Brian"."Brian Griffin".
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 literal. Since the ontology axiom restricts a:hasName to be functional and a:Brian is connected by a:hasName to "Brian","Brian Griffin", it is classified as an instance of this class expression.

9 Axioms

OWL 2 ontologies consist of axioms —statements that say what is true in the domain being modeled. OWL 2 provides an extensive set of axioms, all of which extend the Axiom class in the structural specification. Axioms in OWL 2 can be annotated, as described in Section 10 . The annotations have no effect on the semantics of axioms — that is, they do not affect the OWL 2 meaning [ OWL 2 Direct Semantics ].the structural specification. As shown in Figure 12, axioms in OWL 2 can be declarations, axioms about classes, axioms about object or data properties, keys, assertions (sometimes also called facts), and entityaxioms about annotations.

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

Axiom  :=:= Declaration | ClassAxiom | ObjectPropertyAxiom | DataPropertyAxiom | HasKey | Assertion | EntityAnnotation | AnonymousIndividualAnnotationAnnotationAxiom

axiomAnnotations:= { Annotation }

As shown in Figure 1, OWL 2 axioms can contain axiom annotations, the structure of which is defined in Section 10. Annotations on axioms affect their structural equivalence: for two axioms to be structurally equivalent, the annotations on them MUST be structurally equivalent as well. In contrast, axiom annotations have no effect on the semantics of axioms that is, they do not affect the meaning of OWL 2 ontologies [OWL 2 Direct Semantics].

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

SubClassOf( Annotation( rdfs: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 OWL 2 Direct Semantics [OWL 2 Direct Semantics].

SubClassOf( a:Man a:Person )

9.1 Class Expressions Axioms

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

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

ClassAxiom  :=:= SubClassOf | EquivalentClasses | DisjointClasses | DisjointUnion

9.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 a fundamental type of axioms in OWL 2 and can be used to construct a class hierarchy.

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

Consider the ontology consisting of the following axioms.

SubClassOf( a:Baby a:Child ) Each instance of a:Babybaby is an instance of a:Child .a child.
SubClassOf( a:Child a:Person ) Each instance of a:Childchild is an instance of a:Person .a person.
ClassAssertion( a:Baby a:Stewie ) a:StewieStewie 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 subclassaxiom 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.Each boy is a child.
SubClassOf( a:Girl a:Child ) Girls are children.Each girl is a child.
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 semantics of OWL 2, this does not implymean that 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:Parent ).

9.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 }axiomAnnotations 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:ChrisChris is a child.
ClassAssertion( a:Man a:Chris ) a:ChrisChris is a man.
ClassAssertion( a:Boy a:Stewie ) a:StewieStewie 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 ) AEach mongrel is a type ofdog.
ClassAssertion( a:MongrelOwner a:Peter ) a:PeterPeter 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:DowOwnera:DogOwner ). By the fourth axiom, a:Peter is then classified as an instance of a:DogOwner.

9.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 }axiomAnnotations 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:StewieStewie 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.

9.1.4 Disjoint Union of Class Expressions

A disjoint union axiom DisjointUnion( 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 is an instance of exactly one CEi, and each instance of CEi is an instance of C. Each such axiom iscan be seen as a syntactic shortcut for the following two axioms:

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

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

Consider the ontology consisting of the following axioms.

DisjointUnion( a:Child a:Boy a:Girl ) a:ChildEach child is either a boy or a girl, each boy is a child, each girl is a disjoint union of a:Boychild, and a:Girl .nothing can be both a boy and a girl.
ClassAssertion( a:Child a:Stewie ) a:StewieStewie is a child.
ClassAssertion( ComplementOf( a:Girl ) a:Stewie ) a:StewieStewie 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.

9.2 Object Property Axioms

OWL 2 provides axioms that can be used to characterize object property expressions. For clarity, the structure of these axioms is shown in two separate figures, Figure 14 and Figure 15. The SubObjectPropertyOf axiom allows one to state that the extension of one object property expression is included in the extension of another object property expression. The EquivalentObjectProperties axiom allows one to state that the extensions of several object property expressions are the same. The DisjointObjectProperties axiom allows one to state that the extensions of several object property expressions are disjoint with each other —that is, that 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

9.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 ). 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 ). This axiom states thatthat, 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].

SubObjectPropertyOf:= 'SubPropertyOf' '(' axiomAnnotations subObjectPropertyExpressions superObjectPropertyExpression ')'
subObjectPropertyExpressions:= ObjectPropertyExpression | propertyExpressionChain
 :=propertyExpressionChain:= 'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
subObjectPropertyExpression  := ObjectPropertyExpression | propertyExpressionChain SubObjectPropertyOf  := 'SubPropertyOf' '(' { Annotation } SubObjectPropertyExpressionsuperObjectPropertyExpression:= 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 asBrian is a dog.dog of Peter.

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 aThe sister of x 's mother.someone's mother is that person's aunt.
PropertyAssertion( a:hasMother a:Stewie a:Lois ) a:LoisLois is the mother of a:Stewie .Stewie.
PropertyAssertion( a:hasSister a:Lois a:Carol ) a:CarolCarol is a sister of a:Lois .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 ).

9.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 }axiomAnnotations ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'

Consider the ontology consisting of the following axioms.

EquivalentProperties( a:hasBrother a:hasMaleSibling ) a:hasBrother and a:hasMaleSibling are synonyms.Having a brother is the same as having a male sibling.
PropertyAssertion( a:hasBrother a:Chris a:Stewie ) a:Chris hasStewie is a brother a:Stewie .of Chris.
PropertyAssertion( a:hasMaleSibling a:Stewie a:Chris ) a:Stewie hasChris is a male sibling a:Chris .of Stewie.

Since a:hasBrother and a:hasMaleSibling are equivalent properties, this ontology entails that a:Chris is connected by a:hasMaleSibling 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 ).

9.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 ⟩individual x can at the same timebe connected to an individual y by both OPEi and OPEj for i ≠j.

DisjointObjectProperties  :=:= 'DisjointProperties' '(' { Annotation }axiomAnnotations 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:PeterPeter is the father of a:Stewie .Stewie.
PropertyAssertion( a:hasMother a:Stewie a:Lois ) a:LoisLois is the mother of a:Stewie .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.

9.2.4 Object Property Domain

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

SubClassOf( SomeValuesFrom( OPE owl:Thing ) CE )

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

Consider the ontology consisting of the following axioms.

PropertyDomain( a:hasDog a:Person ) The domain of a:hasDog is a:Person .Only people can own dogs.
PropertyAssertion( a:hasDog a:Peter a:Brian ) a:Peter has a:Brian asBrian is a dog.dog of Peter.

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 ClassAssertion( a:Person a:Peter ).

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. This, however, is not the case in OWL 2: as shown in the previous paragraph, the missing type is inferred from the domain constraint.

9.2.5 Object Property Range

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

SubClassOf( owl:Thing AllValuesFrom( OPE CE ) )

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

Consider the ontology consisting of the following axioms.

PropertyRange( a:hasDog a:Dog ) The range of the a:hasDog property is the class a:Dog.
PropertyAssertion( a:hasDog a:Peter a:Brian ) a:Peter has a:Brian asBrian is a dog.dog of Peter.

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(ClassAssertion( a:Brian a:Dog ).

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. This, however, is not the case in OWL 2: as shown in the previous paragraph, the missing type is inferred from the range constraint.

9.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 withto an individual y, then y is also connected by OPE2 withto x, and vice versa. ThisEach such axiom can be seen as equivalent toa syntactic shortcut for the following axiom:

EquivalentProperties( OPE1 InverseOf( OPE2 ) )

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

Consider the ontology consisting of the following axioms.

InverseProperties( a:hasFather a:fatherOf ) Having a father is the object properties a:hasFather and a:fatherOf are inverse to each other.opposite of being a father of someone.
PropertyAssertion( a:hasFather a:Stewie a:Peter ) a:Stewie hasPeter is the father a:Peter .of Stewie.
PropertyAssertion( a:fatherOf a:Peter a:Chris ) a:PeterPeter is the father of a:Chris .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 ).

9.2.7 Functional Object Properties

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

SubClassOf( owl:Thing MaxCardinality( 1 OPE ) )

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

Consider the ontology consisting of the following axioms.

FunctionalProperty( a:hasFather ) Each personobject can have at most one father.
PropertyAssertion( a:hasFather a:Stewie a:Peter ) a:Stewie hasPeter is the father a:Peter .of Stewie.
PropertyAssertion( a:hasFather a:Stewie a:Peter_Griffin ) a:Stewie hasPeter Griffin is the father a:Peter_Griffin .of Stewie.

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 SameIndividual( 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. OWL 2, however, does not have 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.

9.2.8 Inverse-Functional Object Properties

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

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

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

Consider the ontology consisting of the following axioms.

InverseFunctionalProperty( a:fatherOf ) Each personobject can have at most one father.
PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:PeterPeter is the father of a:Stewie .Stewie.
PropertyAssertion( a:fatherOf a:Peter_Griffin a:Stewie ) a:Peter_GriffinPeter Griffin is the father of a:Stewie .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. OWL 2, however, does not have 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.

9.2.9 Reflexive Object Properties

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

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

Consider the ontology consisting of the following axioms.

ReflexiveProperty( a:knows ) Everybody knows themself.themselves.
ClassAssertion( a:Person a:Peter ) a:PeterPeter 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 ).

9.2.10 Irreflexive Object Properties

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

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

Consider the ontology consisting of the following axioms.

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

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.

9.2.11 Symmetric Object Properties

An object property symmetry axiom SymmetricProperty( OPE ) states that the object property expression OPE is symmetric —that is, if an individual x is connected by OPE to an individual y, then y is also connected by OPE to x. ThisEach such axiom can be seen as equivalent toa syntactic shortcut for the axiomfollowing axiom:

SubPropertyOf( OPE InverseOf( OPE ) )

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

Consider the ontology consisting of the following axioms.

SymmetricProperty( a:friend ) The property a:friendIf x is a friend of y, they y is symmetric.a friend of x.
PropertyAssertion( a:friend a:Peter a:Brian ) a:BrianBrian is a friend of a:Peter .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 ).

9.2.12 Asymmetric Object Properties

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

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

Consider the ontology consisting of the following axioms.

AsymmetricProperty( a:parentOf ) The property a:parentOfIf x is a parent of y, they y is asymmetric.not a parent of x.
PropertyAssertion( a:parentOf a:Peter a:Stewie ) a:PeterPeter is a parent of a:Stewie .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.

9.2.13 Transitive Object Properties

An object property transitivity axiom TransitiveProperty( OPE ) states that the object property expression OPE is transitive —that is, if an individual x is connected by OPE to an individual y that is connected by OPE to an individual z, then x is also connected by OPE to z. ThisEach such axiom can be seen as equivalent toa syntactic shortcut for the axiomfollowing axiom:

SubPropertyOf( PropertyChain( OPE OPE ) OPE )

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

Consider the ontology consisting of the following axioms.

TransitiveProperty( a:ancestorOf ) The property a:ancestorOfIf x is an ancestor of y and y is an ancestor of z, then x is transitive.an ancestor of z.
PropertyAssertion( a:ancestorOf a:Carter a:Lois ) a:CarterCarter is an ancestor of a:Lois .Lois.
PropertyAssertion( a:ancestorOf a:Lois a:Meg ) a:LoisLois is an ancestor of a:Meg .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 ).

9.3 Data Property Axioms

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

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

9.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 withto a literal y, then x is connected by OPE2 withto y as well.

SubDataPropertyOf  :=:= 'SubPropertyOf' '(' { Annotation }axiomAnnotations subDataPropertyExpression superDataPropertyExpression ')'
subDataPropertyExpression:= DataPropertyExpression
superDataPropertyExpression:= DataPropertyExpression

')'Consider the ontology consisting of the following axioms.

SubPropertyOf( a:hasFirstNamea:hasLastName a:hasName ) Having a firstlast name is a kind of having a name.
PropertyAssertion( a:hasFirstNamea:hasLastName a:Peter "Peter""Griffin" ) a:Peter has firstPeter's last name "Peter".is "Griffin".

Since a:hasFirstNamea:hasLastName is a subproperty of a:hasName, each individual connected by the former property to a literal is also connected by the latter property to the same literal. Therefore, this ontology entails that a:Peter is connected to "Peter" through a:hasName; that is, the ontology entails the assertion PropertyAssertion( a:hasName a:Peter "Peter" ).

9.3.2 Equivalent Data Properties

An equivalent data properties axiom EquivalentProperties( DPE1 ... DPEn ) states that all the data property expressions DPEi, 1 ≤i ≤n, are semantically equivalent to 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 understoodseen as equivalent toa syntactic shortcut for the following two axioms:axiom:

SubPropertyOf( DPE1 DPE2 )
SubPropertyOf( DPE2 DPE1 )

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

Consider the ontology consisting of the following axioms.

EquivalentProperties( a:hasName a:seLlama ) a:hasBrothera:hasName and a:seLlama (in Spanish) are synonyms.
PropertyAssertion( a:hasName a:Chris "Chris"a:Meg "Meg Griffin" ) a:Chris hasMeg's name "Chris".is "Meg Griffin".
PropertyAssertion( a:seLlama a:Chris "Chrisa:Meg "Megan Griffin" ) a:Chris hasMeg's name "Chris Griffin".is "Megan Griffin".

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

9.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 x can at the same timebe connected with someto a literal y throughby both DPEi and DPEj for i ≠j.

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

Consider the ontology consisting of the following axioms.

DisjointProperties( a:hasName a:hasAddress ) The values for aSomeone's name aremust be different from the values for anhis address.
PropertyAssertion( a:hasName a:Peter "Peter""Peter Griffin" ) a:Peter hasPeter's name "Peter".is "Peter Griffin".
PropertyAssertion( a:hasAddress a:Peter "Quahog, Rhode Island" ) a:Peter hasPeter's address is "Quahog, Rhode Island".Island".

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

9.3.4 Data Property Domain

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

SubClassOf( SomeValuesFrom( DPE rdfs:Literal) CE )

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

Consider the ontology consisting of the following axioms.

PropertyDomain( a:hasName a:Person ) The domain of a:hasName is a:Person .Only people can have names.
PropertyAssertion( a:hasName a:Peter "Peter""Peter Griffin" ) a:Peter hasPeter's name "Peter".is "Peter Griffin".

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 ClassAssertion( a:Person a:Peter ).

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. This, however, is not the case in OWL 2: as shown in the previous paragraph, the missing type is inferred from the domain constraint.

9.3.5 Data Property Range

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

SubClassOf( owl:Thing AllValuesFrom( DPE DR ) )

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

Consider the ontology consisting of the following axioms.

PropertyRange( a:hasName xsd:string ) The range of a:hasDogthe a:hasName property is a:Dogxsd:string.
PropertyAssertion( a:hasName a:Peter "Peter""Peter Griffin" ) a:Peter hasPeter's name "Peter".is "Peter Griffin".

By the first axiom, each literal 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^^"42"^^xsd:integer ), the range axiom would imply that 42^^the literal "42"^^xsd:integer is in xsd:string, which is a contradiction; therefore, the ontology would become inconsistent.

9.3.6 Functional Data Properties

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

SubClassOf( owl:Thing MaxCardinality( 1 DPE ) )

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

Consider the ontology consisting of the following axioms.

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

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

9.4 Keys

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

Key Axioms in OWL 2
Figure 17. Key Axioms in OWL 2

HasKey  :=:= 'HasKey' '(' { Annotation }axiomAnnotations ClassExpression ObjectPropertyExpression | DataPropertyExpression { ObjectPropertyExpression | DataPropertyExpression } ')'

Consider the ontology consisting of the following axioms.

HasKey( a:Person a:hasSSN ) Each person is uniquely identified by their social security number.
PropertyAssertion( a:hasSSN a:Peter "123-45-6789" ) a:Peter has thePeter's social security number "123-45-6789".is "123-45-6789".
ClassAssertion( a:Person a:Peter ) a:PeterPeter is an instance of a:Person .a person.
PropertyAssertion( a:hasSSN a:Peter_Griffin "123-45-6789" ) a:Peter_Griffin has thePeter Griffin's social security number "123-45-6789".is "123-45-6789".
ClassAssertion( a:Person a:Peter_Griffin ) a:Peter_GriffinPeter Griffin is an instance of a:Person .a person.

The first axiom makes a:hasSSN the key for individuals in the class a:Person , effectively requiring each; thus, if an instance of a:Person to havehas a uniquevalue for a:hasSSN ., then this value must be unique. Since the values of a:hasSSN are the same for a:Peter and a:Peter_Griffin, these two individuals 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 the a:hasSSN has the same value for two individuals a:Peter and a:Peter_Griffin. However, OWL 2 does not have 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.

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

Consider the ontology consisting of the following axioms.

HasKey( a:Person a:hasSSN ) Each person is uniquely identified by their social security number.
PropertyAssertion( a:hasSSN a:Peter "123-45-6789" ) a:Peter has thePeter's social security number "123-45-6789"."123-45-6789".
ClassAssertion( a:Person a:Peter ) a:PeterPeter is an instance of a:Person .a person.
ClassAssertion(
   SomeValuesFrom(
      a:marriedTo
      IntersectionOf( a:Man HasValue( a:hasSSN "123-45-6789" ) )
   )
   a:Lois
) 		a:LoisLois is married to someone who is a a:Man andsome man whose social security number is "123-45-6789"."123-45-6789".
SubClassOf( a:Man a:Person ) Each man is a person.

The fourth axiom implies existence of some individual x that is an instance of a:Man and whose value for the a:hasSSN data property is "123-45-6789";"123-45-6789"; by the fifth axiom, x is an instance of a:Person as well. Furthermore, the second and the third axiom say that a:Peter is an instance of a:Person and that the value of a:hasSSN for a:Peter is "123-45-6789"."123-45-6789". Finally, the first axiom says that a:hasSSN is a key property for instances of a:Person. Thus, one might intuitively expect x to be equal to a:Peter, and for the ontology to entail the assertion ClassAssertion( a:Man a:Peter ).

The inferences in the previous paragraph, however, cannot be drawn because of the DL-safe semantics of key axioms: x is an individual that has not been explicitly named in the ontology; therefore, the semantics of key axioms does not apply to x. Therefore, this OWL 2 ontology does not entail the assertion ClassAssertion( a:Man a:Peter ).

9.5 Assertions

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

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

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

Object Property Assertions
Figure 19. Object Property Assertions

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

Data Property Assertions
Figure 20. Data Property Assertions

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

sourceIndividual  :=:= Individual
targetIndividual  :=:= Individual
targetValue  :=:= Literal

9.5.1 Individual Equality

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

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

Consider the ontology consisting of the following axioms.

SameIndividual( a:Meg a:Megan ) a:MegMeg and a:MeganMegan are synonyms.the same objects.
PropertyAssertion( a:hasBrother a:Meg a:Stewie ) a:MegMeg has a brother a:Stewie .Stewie.

Since a:Meg and a:Megan are synonyms,equal, 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 ) )..

9.5.2 Individual Inequality

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

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

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:fatherOf a:Peter a:Meg ) a:PeterPeter is athe father of a:Meg .Meg.
PropertyAssertion( a:fatherOf a:Peter a:Chris ) a:PeterPeter is athe father of a:Chris .Chris.
PropertyAssertion( a:fatherOf a:Peter a:Stewie ) a:PeterPeter is athe father of a:Stewie .Stewie.
DifferentIndividuals( a:Peter a:Meg a:Chris a:Stewie ) All of these individualsPeter, Meg, Chris, and Stewie are all different from each other.

The last axiom in this example ontology axiomatizes the unique name assumption (but only for the three names in the axiom). 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.

9.5.3 Class Assertions

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

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

Consider the ontology consisting of the following axioms.

ClassAssertion( a:Dog a:Brian ) a:BrianBrian is a a:Dog .dog.
SubClassOf( a:Dog a:Mammal ) Dogs are mammals.Each dog is a mammal.

The first axiom states that a:Brian is an instance of the class a:Dog. By the second axiom, 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 ) . 9.5.4entails the assertion ClassAssertion( a:Mammal a:Brian ).

9.5.4 Positive Object Property Assertions

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

ObjectPropertyAssertion:= 'PropertyAssertion' '(' axiomAnnotations ObjectPropertyExpression sourceIndividual targetIndividual ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasDog a:Peter a:Brian ) Brian is a dog of Peter.
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 ).

9.5.5 Negative Object Property Assertions

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

NegativeObjectPropertyAssertion:= 'NegativePropertyAssertion' '(' axiomAnnotations objectPropertyExpression sourceIndividual targetIndividual ')'

Consider the ontology consisting of the following axiom.

NegativePropertyAssertion( a:hasSon a:Peter a:Meg ) Meg is not a son of 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.

9.5.6 Positive ObjectData Property Assertions

A positive objectdata property assertion PropertyAssertion( OPE a 1DPE a 2lt ) states that the individual a 1is connected by the objectdata property expression OPEDPE to the individual a 2literal lt.

ObjectPropertyAssertion  :=DataPropertyAssertion:= 'PropertyAssertion' '(' { Annotation } ObjectPropertyExpressionaxiomAnnotations DataPropertyExpression sourceIndividual targetIndividualtargetValue ')'

Consider the ontology consisting of the following axioms.

PropertyAssertion( a:hasDog a:Peter a:Briana:hasAge a:Meg "17"^^xsd:integer ) a:Peter has dog a:Brian .Meg is seventeen years old.
SubClassOf(
SomeValuesFrom( a:hasDog owl:Thinga:hasAge
DatatypeRestriction( xsd:integer
xsd:minInclusive "13"^^xsd:integer
xsd:maxInclusive "19"^^xsd:integer
)
a:DogOwner)
a:Teenager
) 		Things having a dogolder than 13 and younger than 19 (both inclusive) are dog owners.teenagers.

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

9.5.59.5.7 Negative ObjectData Property Assertions

A negative objectdata property assertion NegativePropertyAssertion( OPE a 1DPE a 2lt ) states that the individual a 1is not connected by the objectdata property expression OPEDPE to the individual a 2literal lt.

NegativeObjectPropertyAssertion  :=NegativeDataPropertyAssertion:= 'NegativePropertyAssertion' '(' { Annotation } objectPropertyExpressionaxiomAnnotations DataPropertyExpression sourceIndividual targetIndividualtargetValue ')'

Consider the ontology consisting of the following axiom.

NegativePropertyAssertion( a:hasSon a:Petera:hasAge a:Meg "5"^^xsd:integer ) a:MegMeg 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.

10 Annotations

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

One might want to associate human-readable labels with URIs and use them when visualizing an assertion PropertyAssertion( a:hasSon a:Peter a:Meg ) ,ontology. To this end, one might use the negative objectrdfs:label annotation property assertion would be invalidated andto associate the labels with ontology would become inconsistent. 9.5.6 Positive Data Property Assertions A positive data property assertion PropertyAssertion( DPE a lt ) states thatURIs.

Various OWL 2 syntaxes, such as the individualfunctional-style syntax, provide a is connected by the data property expression DPE to the literal lt . DataPropertyAssertion  := 'PropertyAssertion' '(' { Annotation } DataPropertyExpression sourceIndividual targetValue ')' Consider themechanism for embedding comments into ontology consisting ofdocuments. The following axioms. PropertyAssertion( a:hasAge a:Meg 17^^xsd:integer ) a:Megstructure of such comments, however, 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).dependent on the first axiom states that a:Megsyntax, so representing them in the structural specification is connected by a:hasAgelikely to 17^^ xsd:integer . Bybe difficult or even impossible; hence, such comments are simply discarded during parsing. In contrast, annotations are "first-class citizens" in the second axioms, each individual connected by a:hasAge to an integer between 13structural specification of OWL 2, and 19their structure is an instanceindependent of a:Teenager . Therefore, this ontology entails that a:Megthe underlying syntax.

Since it is an instancebased on XML, the OWL 2 XML Syntax [OWL 2 XML Syntax] allows the embedding of a:Teenager — that is,the standard XML comments into ontology entails the assertion ClassAssertion( a:Teenager a:Meg ) . 9.5.7 Negative Data Property Assertions A negative data property assertion NegativePropertyAssertion( DPE a lt ) states that the individual a isdocuments. Such comments are not connected byrepresented in the data property expression DPE tostructural specification of OWL 2 and, consequently, they should be ignored during document parsing.

10.1 Annotations of Ontologies, Axioms, and other Annotations

Ontologies, axioms, and annotations themselves can be annotated using annotations shown in Figure 21. As shown in the literal lt . NegativeDataPropertyAssertion  := 'NegativePropertyAssertion'figure, such annotations consist of an annotation property and an annotation value, where latter can be anonymous individuals, URIs, and literals.

Annotations in OWL 2
Figure 21. Annotations of Ontologies and Axioms in OWL 2

Annotation:= 'Annotation' '(' annotationAnnotations AnnotationProperty AnnotationValue ')'
annotationAnnotations := { Annotation }
DataPropertyExpression sourceIndividual targetValue ')' ConsiderAnnotationValue:= AnonymousIndividual | URI | Literal

10.2 Annotation Axioms

OWL 2 provides means to state several types of axioms about annotation properties, as shown in Figure 22. These axioms have no effect on the ontology consistingDirect Semantics of OWL 2 [OWL 2 Direct Semantics], and they are made axioms in order to simplify the structural specification of OWL 2. OWL 2 tools can interpret these axioms metalogically; for example, OWL 2 APIs can provide primitives that implement the following axiom. NegativePropertyAssertion( a:hasAge a:Meg 5^^ xsd:integer ) a:Meg is not five years old. If this ontology were extended withintended meaning of these axioms.

Annotations of URIs and Anonymous Individuals in OWL 2
Figure 22. Annotations of URIs and Anonymous Individuals in OWL 2

AnnotationAxiom:= AnnotationAssertion | SubAnnotationPropertyOf | AnnotationPropertyDomain | AnnotationPropertyRange

10.2.1 Annotation Assertion

An annotation assertion PropertyAssertion( a:hasAge a:Meg 5^^ xsd:integerAnnotationAssertion( AP as at ) ,states that the negative dataannotation subject as a URI or an anonymous individual is annotated with the annotation property assertion would be invalidatedAP and the ontology would become inconsistent. 10 Annotations OWL 2 applications often need ways to associate information with ontologies, entities, andannotation value av. Such axioms in a way that does not affecthave no effect on the logical meaningDirect Semantics of the ontology. Such information often plays a central role inOWL 2 applications. Although such information is not expected to affect[OWL 2 Direct Semantics].

AnnotationAssertion:= 'AnnotationAssertion' '(' axiomAnnotations AnnotationProperty AnnotationSubject AnnotationValue ')'
AnnotationSubject:= URI | AnonymousIndividual

The formal meaning of an ontology (i.e., it is not expectedfollowing axiom assigns a human-readable comment to affectthe URI a:Person.

AnnotationAssertion( rdfs:label a:Person "Represents the set of logical consequences that one can derive from an ontology), it is expected to be accessible inall people." )

Since the structural specification of OWL 2.annotation is assigned to this end, OWL 2 provides for annotations on ontologies, axioms, and entities. One might wanta URI, it applies to associate human-readable labels withall entities with the given URI. Thus, if an ontology contains both a class and use them when visualizingan ontology.individual a:Person, the above comment applies to this end, one might useboth entities.

10.2.2 Annotation Subproperties

An annotation subproperty axiom SubPropertyOf( AP1 AP2 ) states that the rdfs:labelannotation property to associateAP1 is a subproperty of the labels with ontology entities. Certainannotation property AP2. Such axioms have no effect on the Direct Semantics of OWL 2 [OWL 2 Direct Semantics].

SubAnnotationPropertyOf:= 'SubPropertyOf' '(' axiomAnnotations subAnnotationProperty superAnnotationProperty ')'
subAnnotationProperty:= AnnotationProperty
superAnnotationProperty:= AnnotationProperty

Although annotation subproperty axioms do not have a formal semantics, OWL 2 provide a mechanism for embedding commentstools can choose to take their intuitive semantics into ontology documents.account when answering questions about annotations. Consider the structureontology consisting of such comments, however,the following axioms.

SubPropertyOf( a:englishLabel rdfs:label ) Having an English label is dependent ona kind of having a label.
AnnotationAssertion( a:englishLabel a:Dog "dog" ) The syntax, so representing them inlabel for the structural specificationURI a:Dog is likely"dog".

When asked to be difficult or even impossible; hence, such comments are simply discarded during parsing. In contrast, annotations are "first-class citizens" inreturn the structural specification of OWL 2, and their structure is independentvalues of the underlying syntax. Since it is based on XML,rdfs:label annotation property for the URI a:Dog, an OWL 2 XML Syntax [tool could choose to return "dog". If an OWL 2 XML Syntax ] allows the embedding of the standard XML comments into ontology documents.tool chooses to provide such comments are not representeda feature, it is expected to cleanly separate such metalogical queries from the more common logical queries presented in the structural specification of OWL 2 and, consequently, they should be ignored during document parsing. 10.1previous sections.

10.2.3 Annotation ValuesProperty Domain

An annotation consistsproperty domain axiom PropertyDomain( AP U ) states that the domain of anthe annotation property and a value forAP is the annotation.URI U. Such axioms have no effect on the Direct Semantics of OWL 2 allows for three kinds of annotation values, as shown in Figure 21.[OWL 2 Direct Semantics].

AnnotationPropertyDomain:= 'PropertyDomain' '(' axiomAnnotations AnnotationProperty URI ')'

Although annotation values can be literals. Note that these needsubproperty axioms do not be just strings; rather, anyhave a formal semantics, OWL 2 literaltools can be used.choose to take their intuitive semantics into account. A common interpretation is to treat these annotation values can beproperty domain axioms as integrity constraints. Consider the ontology entities. Such annotations make it clearer thatconsisting of the following axioms.

PropertyDomain( a:dogImageURI a:Dog ) The objects annotated by the value is not just some literal, but an entity from this or some other ontology.annotation values canproperty a:dogImageURI must be anonymous individuals. Figure 21. Annotations in OWL 2instances of a:Dog.
ClassAssertion( a:Dog a:Brian ) Brian is a dog.
AnnotationAssertion( a:dogImageURI a:Brian <http://www.example.com/images/brian.jpg> ) Specifies the functional-style syntax forURI of Brian's image.

An OWL 2 provides an abbreviation mechanism for annotations withtool could use the first axiom to check whether the common rdfs:label and rdfs:commentannotation properties, and for abbreviating annotationsproperty a:dogImageURI was applied only to instances of the form Annotation( owl:deprecated "true"^^ xsd:boolean )a:Dog. These are purely syntactic abbreviations and are not reflected in the structural specificationSince a:Brian is an instance of OWL 2. explicitAnnotationByLiteral  := 'Annotation' '(' { Annotation } AnnotationProperty Literal ')' labelAnnotation  := 'Label' '(' { Annotation } Literal ')' commentAnnotation  := 'Comment' '(' { Annotation } Literal ')' deprecationAnnotation  := 'Deprecated' [ '(' { Annotation } ')' ] AnnotationByLiteral  := explicitAnnotationByLiteral | labelAnnotation | commentAnnotation | deprecationAnnotation AnnotationByEntity  := 'Annotation' '(' { Annotation } AnnotationProperty Entity ')' AnnotationByAnonymousIndividual  := 'Annotation' '(' {a:Dog, the last annotation } AnnotationProperty AnonymousIndividual ')'satisfies the annotation  := AnnotationByLiteral | AnnotationByEntity | AnnotationByAnonymousIndividual 10.2 Annotations of Axioms and Ontologies Annotations can be associated with axioms and ontologies, as shown in Figure 1. Annotations on axioms and ontologies affect their structural equivalence. Thus, for two axiomsproperty domain axiom. If an OWL 2 tool chooses to provide such a feature, it is expected 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,cleanly separate such metalogical queries from the syntax for annotating them has beenmore common logical queries presented in the previous sections of this document. The followingsections.

10.2.4 Annotation Property Range

An annotation property range axiom contains a commentPropertyRange( AP U ) states that explainsthe purposerange of the axiom. SubClassOf( Comment("Male people are people.") a:Man a:Person ) Since annotations affect structural equivalence between axioms, the previous axiomannotation property AP is NOT structurally equivalent withthe following axiom, even though these twoURI U. Such axioms are equivalent according tohave no effect on the Direct Semantics of OWL 2. SubClassOf( a:Man a:Person ) 10.3 Annotations of Entities and Anonymous Individuals Annotations are attached to entities and anonymous individuals using entity and anonymous individual2 [OWL 2 Direct Semantics].

AnnotationPropertyRange:= 'PropertyRange' '(' axiomAnnotations AnnotationProperty URI ')'

Although annotation axioms , shown in Figure 22. Suchsubproperty axioms do not affect the semantics of anhave a formal semantics, OWL 2 ontology, and they are made axioms in ordertools can choose to simplifytake their intuitive semantics into account. A common interpretation is to treat these annotation property range axioms as integrity constraints. Consider the structural specification of OWL 2. Each such axiom provides for two typesontology consisting of the following axioms.

PropertyRange( rdfs:label xsd:string ) The annotation property rdsf:label can be used only in annotations — one forwith a string value.
AnnotationAssertion( rdfs:label a:Dog "dog" ) The axiom itself and onelabel for the entity. ItURI a:Dog is important to distinguish these two types of annotation: the first one refers to"dog".

An OWL 2 tool could use the first axiom (e.g., it says who has asserted it), whereas the second one refersto check whether the entity/anonymous individual itself (e.g., it provides a human-friendly label). Figure 22. Annotationsvalues of Entities and Anonymous Individuals in OWL 2 axiomAnnotations  := { Annotation } targetAnnotations  :=annotations with the rdfs:label annotation {property are of appropriate type. Since "dog" is a string, the second annotation } EntityAnnotation  := 'EntityAnnotation' '(' axiomAnnotations Entity targetAnnotations ')' AnonymousIndividualAnnotation  := 'AnonymousIndividualAnnotation' '(' axiomAnnotations AnonymousIndividual targetAnnotations ')'satisfies the following axiom assignsannotation property range axiom. If an OWL 2 tool chooses to provide such a human-readable commentfeature, it is expected to cleanly separate such metalogical queries from the class a:Person . EntityAnnotation( Class( a:Person ) Comment( "Represents all peoplemore common logical queries presented in the domain." ) )previous sections.

11 Global Restrictions on Axioms

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

11.1 Property Hierarchy and Simple Object Property Expressions

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

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

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

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

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

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

Roughly speaking, a simple object property expression has no direct or indirect subproperties that are either transitive or are defined by means of property chains, where the notion of indirect subproperties is captured by the property hierarchy. Consider the following axioms:

SubPropertyOf( PropertyChain( a:hasFather a:hasBrother ) a:hasUncle ) If x is connected by a:hasFather with y , and y is connected by a:hasBrother with z , then x is connected by a:hasUncle with z ; that is, an uncle z of x is aThe brother of x 's father.someone's father is that person's uncle.
SubPropertyOf( a:hasUncle a:hasRelative ) Having an uncle is a kind of having a relative.
SubPropertyOf( a:hasBiologicalFather a:hasFather ) Having a biological father is a kind of having a father.

The object property a:hasUncle occurs in a SubObjectPropertyOfan object subproperty axiom involving a property chain, so it is not simple. Consequently, the object property a:hasRelative is not simple either, because a:hasUncle is a nonsimple subproperty of a:hasRelative. In contrast, the object property a:hasBiologicalFather is asimple, and so is a:hasFather.

11.2 The Restrictions on the Axiom Closure

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

The first two restrictions merely prohibit the usage of nonsimple properties in number restrictions and in certain axioms about object properties. The third restriction prohibitslimits the usage of owl:TopObjectProperty andowl:topDataProperty in subproperty axioms.. Without it, owl:topDataProperty could be used to write axioms about datatypes, which would invalidate Theorem 1 from the OWL 2 Direct Semantics [OWL 2 Direct Semantics].

The main goal of the fourth restriction is to prevent cyclic definitions involving SubObjectPropertyOfobject subproperty axioms with property chains. Consider the following ontology:

SubPropertyOf( PropertyChain( a:hasFather a:hasBrother ) a:hasUncle ) If x is connected by a:hasFather with y , and y is connected by a:hasBrother with z , then x is connected by a:hasUncle with z ; that is, an uncle z of x is aThe brother of x 's father.someone's father is that person's uncle.
SubPropertyOf( PropertyChain( a:hasChild a:hasUncle ) a:hasBrother ) If x is connected by a:hasChild with y , and y is connected by a:hasUncle with z , then x is connected by a:hasBrother with z ; that is, a brother z of x is anThe uncle of x 's child.someone's child is that person's brother.

The first axiom defines a:hasUncle in terms of a:hasBrother, while the second axiom defines a:hasBrother in terms of a:hasUncle. These two axioms are thus cyclic: the first one depends on the second one and vice versa. Such cyclic definitions are known to lead to undecidability of the basic reasoning problems. Thus, these two axioms mentioned above cannot occur together in an axiom closure of an OWL 2; however, each axiom alone canmay be allowed (depending on the other axioms in the closure).

A particular kind of cyclic definitions is known not to lead to decidability problems. Consider the following ontology:

SubPropertyOf( PropertyChain( a:hasChild a:hasSibling ) a:hasChild ) The sibling of someone's child is that person's child.

The above definition is cyclic, since the object property a:hasChild occurs in both the subproperty chain and as a superproperty. Axioms of this form, however, do not violate the global restrictions of OWL 2.

The fifth and the sixth restriction ensure that each OWL 2 ontology with anonymous individuals can be transformed to an equivalent ontology without anonymous individuals. Roughly speaking, this is possible if xproperty assertions connect anonymous individuals in a tree-like way. Consider the following ontology:

PropertyAssertion( a:hasChild a:Francis _:x ) Francis has some (unknown) child.
PropertyAssertion( a:hasChild _:x a:Meg ) This unknown child has Meg...
PropertyAssertion( a:hasChild _:x a:Chris ) ...Chris...
PropertyAssertion( a:hasChild _:x a:Stewie ) ...and Stewie as children.

The connections between individuals a:Francis, a:Meg, a:Chris, and a:Stewie can be understood as a tree that contains _:x as its internal node. Because of that, the anonymous individuals can be "rolled-up"; that is, these four assertions can be replaced by the following equivalent assertion:

ClassAssertion(
SomeValuesFrom( a:hasChild
IntersectionOf(
HasValue( a:hasChild a:Meg )
HasValue( a:hasChild a:Chris )
HasValue( a:hasChild a:Stewie )
)
)
a:Francis
)

If the anonymous individuals were allowed to be connected by properties in arbitrary ways (and, in particular, in cycles), such a transformation would clearly be impossible. This transformation, however, is connected by a:hasChildnecessary in order to reduce the basic inference problems in OWL 2 to the appropriate description logic reasoning problems with y ,known computational properties [SROIQ].

12 Appendix: Internet Media Type, File Extension, and yMacintosh File Type

Contact
Ivan Herman / Sandro Hawke
See also
How to Register a Media Type for a W3C Specification Internet Media Type registration, consistency of use TAG Finding 3 June 2002 (Revised 4 September 2002)

The Internet Media Type / MIME Type for the OWL functional-style Syntax is connected by a:hasSibling with z , then xtext/owl-functional.

It is connected by a:hasChild with z ;recommended that is, a child z of xOWL functional-style Syntax files have the extension .ofn (all lowercase) on all platforms.

It is recommended that OWL functional-style Syntax files stored on Macintosh HFS file systems be given a siblingfile type of x 's child. The above definition is cyclic, sinceTEXT.

The object property a:hasChild occurs in bothinformation that follows will be submitted to the subproperty chainIESG for review, approval, and as a superproperty. Axioms ofregistration with IANA.

Type name
text
Subtype name
owl-functional
Required parameters
None
Optional parameters
charset This form, however, do not violateparameter may be required when transfering non-ASCII data across some protocols. If present, the global restrictionsvalue of OWL 2.charset should be UTF-8.
Encoding considerations
The fifth andsyntax of the sixth restriction ensure that eachOWL 2 ontology with anonymous individuals can be transformed to an equivalent ontology without anonymous individuals. Roughly speaking, thisfunctional-style Syntax is possible if property assertions connect anonymous individualsexpressed over code points in Unicode [UNICODE]. The encoding should be UTF-8 [RFC3629], but other encodings are allowed.
Security considerations
The OWL functional-style Syntax uses IRIs as term identifiers. Applications interpreting data expressed in the OWL functional-style Syntax should address the security issues of Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8, as well as Uniform Resource Identifiers (URI): Generic Syntax [RFC3986] Section 7. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "o" may appear similar to a tree-like way. Consider the following ontology: PropertyAssertion( a:hasChild a:Francis _:x ) a:Francis is connectedLatin "o"). A character followed by a:hasChild to the anonymous individual _:x . PropertyAssertion( a:hasChild _:x a:Meg )combining characters may have the anonymous individual _:x is connectedsame visual representation as another character (LATIN SMALL LETTER E followed by a:hasChild to a:Meg . PropertyAssertion( a:hasChild _:x a:Chris )COMBINING ACUTE ACCENT has the anonymous individual _:xsame visual representation as LATIN SMALL LETTER E WITH ACUTE). Any person or application that is connected by a:hasChild to a:Chris . PropertyAssertion( a:hasChild _:x a:Stewie )writing or interpreting data in the anonymous individual _:x is connected by a:hasChildOWL functional-style Syntax must take care to a:Stewie .use the connections between individuals a:Francis , a:Meg , a:Chris , and a:Stewie can be understood as a treeIRI that contains _:x as its internal node. Because of that,matches the anonymous individuals can be "rolled-up";intended semantics, and avoid IRIs that is, these four assertionsmay look similar. Further information about matching of similar characters can be replaced by the following equivalent assertion: ClassAssertion(     SomeValuesFrom( a:hasChild        IntersectionOf(           HasValue( a:hasChild a:Meg )           HasValue( a:hasChild a:Chris )           HasValue( a:hasChild a:Stewie )        )     ) ) If the anonymous individuals were allowed to be connected by properties in arbitrary ways (and, in particular,found in cycles), such a transformation would clearly be impossible.Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
Interoperability considerations
There are no known interoperability issues.
Published specification
This specification.
Applications which use this media type
No widely deployed applications are known to currently use this transformation, however,media type. It is necessaryexpected that OWL tools will use this media type in order to reducethe basic inference problemsfuture.
Additional information
None.
Magic number(s)
OWL functional-style Syntax documents may have the strings 'Namespace:' or 'Ontology:' (case dependent) near the beginning of the document.
File extension(s)
".ofn"
Base URI
There are no constructs in the OWL 2functional-style Syntax to change the appropriate description logic reasoning problems with known computational properties [ SROIQ ]. 12Base URI.
Macintosh file type code(s)
"TEXT"
Person & email address to contact for further information
Ivan Herman <ivan@w3.org> / Sandro Hawke <sandro@w3.org>
Intended usage
COMMON
Restrictions on usage
None
Author/Change controller
The OWL functional-style Syntax is the product of the W3C OWL Working Group; W3C reserves change control over this specification.

13 Appendix: Differences from OWL 1 Abstract Syntax

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

12.113.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 aan OWL 1 frame-like axiom.

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

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

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

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

12.213.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 )

1314 Complete Grammar (Normative)

Editor's Note: The complete grammar will be reproduced here for the last call version of the document..

1415 Index

Editor's Note: The index will be created for the last call version of the document.

1516 References

[OWL 2 Direct Semantics]
OWL 2 Web Ontology Language:DirectDirect Semantics Boris Motik, Peter F. Patel-Schneider, Bernardo Cuenca Grau, eds. W3C Editor's Draft, 08 October21 November 2008, http://www.w3.org/2007/OWL/draft/ED-owl2-semantics-20081008/http://www.w3.org/2007/OWL/draft/ED-owl2-semantics-20081121/. Latest version available at http://www.w3.org/2007/OWL/draft/owl2-semantics/.
[OWL 2 XML Syntax]
OWL 2 Web Ontology Language:XMLXML Serialization Boris Motik, Peter Patel-Schneider, eds. W3C Editor's Draft, 08 October21 November 2008, http://www.w3.org/2007/OWL/draft/ED-owl2-xml-serialization-20081008/http://www.w3.org/2007/OWL/draft/ED-owl2-xml-serialization-20081121/. Latest version available at http://www.w3.org/2007/OWL/draft/owl2-xml-serialization/.
[SROIQ]
The Even More Irresistible SROIQ. Ian Horrocks, Oliver Kutz,Kutz and Uli Sattler. In Proc. of the 10th Int. Conf. on Principles of Knowledge Representation and Reasoning (KR 2006). AAAI Press, 2006.
[XML]
Extensible Markup Language (XML) 1.1. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau,Yergeau and John Cowan, eds. W3C Recommendation 16 August 2006, edited in place 29 September 2006.
[XML Namespaces]
Namespaces in XML 1.0 (Second Edition). Tim Bray, Dave Hollander, Andrew Layman,Layman and Richard Tobin, eds. W3C Recommendation 16 August 2006.
[XML Schema Datatypes]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes Second Edition. Paul V. Biron and AshokD. Peterson, S. Gao, A. Malhotra, C. M. Sperberg-McQueen, H. S. Thompson, eds. W3C Recommendation 28 October 2004.Working Draft 20 June 2008.
[RDF Syntax]
RDF/XML Syntax Specification (Revised). Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/rdf-syntax-grammar/.
[BCP 47]
BCP 47 - Tags for Identifying Languages. A. Phillips, M. Davis, eds., IETF, September 2006, http://www.rfc-editor.org/rfc/bcp/bcp47.txt.
[RFC 3987] RFC 3987 - Internationalized Resource Identifiers (IRIs) . M. Duerst, M. Suignard. IETF, January 2005, http://www.ietf.org/rfc/rfc3987.txt . [RFC2119]
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Network Working Group, S. Bradner. Internet Best Current Practice, March 1997.
[RFC3629]
UTF-8, a transformation format of ISO 10646, F. Yergeau, November 2003, http://www.ietf.org/rfc/rfc3629.txt
[RFC3986]
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, January 2005, http://www.ietf.org/rfc/rfc3986.txt
[RFC3987]
RFC 3987 - Internationalized Resource Identifiers (IRIs). M. Duerst and 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,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,Birbeck and S. McCarron, Editors, W3C Working Draft, 26 November 2007, http://www.w3.org/TR/2007/WD-curie-20071126/.
[RDF Test Cases]
RDF Test Cases. Jan Grant and Dave Beckett, Editors, W3C Recommendation 10 February 2004, http://www.w3.org/TR/rdf-testcases/.
[ISO/IEC 10646]
ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. ISO (International Organization for Standardization).
[DL-Safe]
Query Answering for OWL-DL with Rules. Boris Motik, Ulrike Sattler,Sattler and Rudi Studer. Journal of Web Semantics: Science, Services and Agents on the World Wide Web, 3(1):41–60, 2005.
[IEEE 754]
IEEE Standard for Binary Floating-Point Arithmetic. Standards Committee of the IEEE Computer Society
[ISO 8601:2004]
ISO 8601:2004. Representations of dates and times. ISO (International Organization for Standardization).
[RDF]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne and Jeremy J. Carroll, eds., W3C Recommendation 10 February 2004
[RDF:TEXT]
rdf:text: A Datatype for Internationalized Text .Jie Bao andBao, Axel Polleres, eds.,Boris Motik. W3C DraftEditor's Draft, 21 November 2008, http://www.w3.org/2007/OWL/draft/ED-owl2-rdf-text-20081121/. Latest version available at http://www.w3.org/2007/OWL/draft/owl2-rdf-text/.
[UNICODE]
The Unicode Standard Version 3.0, Addison Wesley, Reading MA, 2000, ISBN: 0-201-61633-5, http://www.unicode.org/unicode/standard/standard.html
[UNISEC]
Unicode Security Considerations, Mark Davis and Michel Suignard, July 2008, http://www.unicode.org/reports/tr36
[MOF]
Meta Object Facility (MOF) Core Specification, version 2.0. Object Management Group, OMG Available Specification January 2006.
[UML]
OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2. Object Management Group, OMG Available Specification November 2007.