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

1 Introduction

In this document defines the structure ofspecification, OWL 1.1ontologies are defined in ways intended to be, on the one hand, largely independant of the concrete exchange syntaxes, and yet, on the constructs that are used within them. It provides two different methodsother, sufficient for this, a functional-style syntax for OWL 1.1 ontologies and a structuralthe clear specification of those syntaxes. There are several reasons for this stemming from the content of OWL 1.1 ontologies.fact that some exchange syntaxes (e.g., the canonical RDF/XML) make it difficult to relate OWL 1.1 functional-style syntax is a new linear syntax for OWL 1.1. The functional-style syntax abstracts from exchange syntaxes and thus facilitates accessto and evaluation of the language. The functional-style syntax is suggested for use as an easier-to-read syntax for communication with humans. The functional-style syntax is alsothe basis for the model theory for OWL 1.1.canonical underlying formalisms (i.e., description logics or first order logic). Defining the functional-style syntax is not quite a complete concrete syntax as it currently ignores issuessemantics directly in terms of white space. The functional-style syntax is similarsuch syntaxes would make it much more difficult to theunderstand OWL 1.0 Abstract Syntax; it is, however, not backwards compatible withby making the OWL 1.0 Abstract Syntax, because of several problems withlarge literature available on the OWL 1.0 Abstract Syntax that wouldunderlying formalisms more inaccessible. Similarly, in order to assure decidability (or, in some fragments, polynomial decidability), certain "non-structural" restrictions on axioms need to be imposed. It is very difficult to overcome without sacrificing backwards compatibility. The structural specification of the contents of OWL 1.1 ontologies is provided asclearly and correctly impose these directly on triple structures. Finally, a non-normative waynumber of storingOWL 1.1 ontologies intools, particularly tools that generateAPIs, and modify OWL 1.1 ontologies. Inconcrete syntaxes work at a non-triple level. Given the structural specification an ontology is consideredneed to be a collection of interconnected objects. Moreover, sinceclearly map OWL into terms that make sense for these cases, and the structuredifficulty of several specification tasks when approached from the RDF perspective, OWL 1.1 objects (ontologies, axioms, etc.)is defined using well-understood notionsfirst in terms of composition, sets, and lists, thenon-triple structural specification provides a meansform.

In order to explicitly specify when two objects are structurally equivalent. 2 Basic Definitions Editor's Note: See Issue-4 (syntax reordering) and Issue-82 (Metamodel diagrams).determine the UML notation usedparticular concrete syntax for some bit of OWL, one should consult the corresponding mapping tables in this documentthe corresponding documents. The primary structural specification is restricted to a very limited subsetin terms of UML class diagram notation. The namesdiagrams given in this document, with a canonical functional syntax which instantiates the UML.

Editor's Note: Are we going to make this true: "For reader convenience, you may choose to hide the diagrams, or the grammar, or both."

Conceptually, OWL ontologies can be broken down into the following categories of parts:

• entities --- classes, properties, individuals, etc.; syntactically, these are the sorts of things which are named by URIs; they can be thought of as primitive terms or names;
• expressions --- these are descriptive characterizations of entities; e.g., a class expression defines a class, typically in terms of features of its possible instances, i.e., descriptions of the sort of thing which are members of that class; obviously, expressions are parameterized by the sort of entity they characterize, thus we have class expressions, or property expressions; different sorts of expression have richer or poorer support in OWL; for example, OWL has a rather rich class expression functionality but comparatively poor property expressions;
• axioms --- these make statements, i.e., true or false assertions that relate entities or expressions with other entities or expressions.

These three categories form the logical part of OWL ontologies. Additionally, entities, axioms, and ontologies may be annotated. Annotations have no effect on the logical aspects of an ontology, though they may be significant to tools or critical for applications. In many cases, the point of the logical portion of an ontology is to support the exploitation of the annotation part. The significance of annotations on tools or applications is not defined by the OWL specifications.

Finally, there is one non-logical construct with a pre-defined meaning, owl:imports, which allows distinct ontologies to be combined.

In concrete syntaxes, there may be additional syntactic features such as mechanisms for abbreviating URIs.

2 Basic Definitions

2.1 Associations and Structural Equivalence

Many associations between components of OWL 1.1 ontologies are of one-to-many type; for example, an ObjectUnionOf description contains a set of disjuncts. Usually, it is important to know whether the components in the association are ordered and whether repetitions are allowed. This is made clear by attaching the following UML stereotypes to associations between components:

• The <<set>> stereotype denotes that the associated components are unordered and that repetitions are not allowed.
• The <<list>> stereotype denotes that the associated components are ordered and that repetitions are allowed.

To make this definition precise, it is necessary to say when two ontology components are considered to be the same. This is captured by the notion of structural equivalence, defined as follows. Components o₁ and o₂ are structurally equivalent if the following conditions hold:

• If o₁ and o₂ are atomic values, such as strings, integers, or IRIs (URIs), they are structurally equivalent if they are equal using equality for their atomic type, i.e., they are the same string, integer, or IRI.
• If o₁ and o₂ are sets, they are structurally equivalent if each element of o₁ is structurally equivalent to some element of o₂ and vice versa.
• If o₁ and o₂ are lists, they are structurally equivalent if they contain the same number of elements and each element of o₁ is structurally equivalent to the element of o₂ with the same index.
• If o₁ and o₂ are complex components composed of other components, they are structurally equivalent if
  • both o₁ and o₂ are of the same type,
  • each component of o₁ is structurally equivalent to the corresponding component of o₂, and
  • each association of o₁ is structurally equivalent to the corresponding association of o₂.

For example, the description ObjectUnionOf( Person Animal ) is structurally equivalent to description ObjectUnionOf( Animal Person ) because the order of the elements in a set is not important. Note that structural equivalence is not a semantic notion, as it is based only on comparing object structures defined in this document. For example, ObjectUnionOf( Person ObjectComplementOf( Person ) ) is not structurally equivalent to owl:Thing even though it is semantically equivalent to it.

Although the <<set>> stereotype is widely used in the specification, ontology files written in one of the linear syntaxes (e.g., XML or RDF/XML) are not expected to be duplicate free. Defining the structure of the language using sets, however, facilitates the specification of APIs for manipulating OWL 1.1 ontologies programmatically; furthermore, it provides the basis for the definition of complex operations on OWL 1.1 ontologies, such as retraction of axioms.

2.2 URIs, Namespaces, and Integers

3 Ontologies

3.1 Syntax

The syntax for OWL 1.1 ontology files is defined as follows:

3.2 Ontology URIs

Each ontology can have an ontology URI. If present, this URI must be unique, and it need not be equal to the physical location of the ontology file. For example, a file for an ontology with a URI http://www.my.domain.com/example need not be physically stored in that location. A specification of a mechanism for physically locating an ontology from its ontology URI is not in scope of this specification.

3.3 Axioms

The main component of an OWL 1.1 ontology is the set of axioms that it contains. Note that this definition does not allow repetitions of structurally equivalent axioms in an ontology. OWL 1.1 ontology files are, however, not expected to enforce this and tools can simply eliminate duplicates.

3.4 Ontology Annotations

3.5 Imports

In OWL 1.0, owl:imports was a special annotation URI, which denotes that an ontology imports another ontology. In OWL 1.1, imports are not ontology annotations, but are a separate primitive, as discussed next; the owl:imports annotation property has no built-in meaning.

Each ontology contains a possibly empty set of import constructs. An ontology O directly imports an ontology O' if O contains an import construct whose value is the ontology URI of O'. The relation imports is defined as a transitive closure of the relation directly imports. The axiom closure of an ontology O is the smallest set containing all the axioms of O and of all ontologies that O imports. Intuitively, an import construct states that, when reasoning with an ontology O, one should consider not only the axioms of O, but the entire axiom closure of O.

Figure 1. OWL Ontologies OWL 1.1 allows each axiom to contain annotations. These can be used to associate arbitrary information with an axiom.3.6 Example

Since annotations are part of an axiom, they4 Entities

Entities are to be taken into account inthe definition of structural equivalencefundamental building blocks of axioms. For example,OWL 1.1 ontologies. The axiom SubClassOf( Human Animal )description of entities (e.g., classes, properties, and individuals) and their relations is not structurally equivalent tothe axiom SubClassOf( Comment("Humans arecanonical purpose of an ontology.

NOTE: For readers with a  typelogic background, entities are the elements of  animals.") Human Animal) even thoughthe
 semanticssignature of an OWL ontology.

4.1 Syntax

All entities may have an associated URI. The commonsyntax for writing entity URIs rdfs:label and rdfs:comment are abbreviatedin OWL 1.1 is as follows:

Entities are written usingin the following grammar: annotationURIway:

4.2 Predefined Entities

OWL 1.1 Alldefines several well-known entities are defined by a URI.that have the syntax for writing entity URIs in OWL 1.1 is as follows: datatypeURI := URI owlClassURI := URI objectPropertyURI := URI dataPropertyURI := URI individualURI := URIpredefined semantics. These entities are written in the following way: entity := datatype | owlClass | objectProperty | dataProperty | individual datatype := 'Datatype' '(' datatypeURI ')' owlClass := 'OWLClass' '(' owlClassURI ')' objectProperty := 'ObjectProperty' '(' objectPropertyURI ')' dataProperty := 'DataProperty' '(' dataPropertyURI ')' individual := 'Individual' '(' individualURI ')' OWL 1.1 defines several well-known entities that have the predefined semantics. These entities are identified byidentified by the following predefined URIs:

4.3 Example

5 Class Expressions

5.1 Propositional Connectives

Editor's Note: Would like to have more class expression specific stuff, similar to what's in the Turtle specification [ TURTLE ] 4.2 Object and Data Propertyfirst sentence of the next section. BJP

Class expressions Object propertiescan be combined into more complex expressions,thought of as showdescriptions of sets of individuals, or as descriptions which are true (or false) of particular individuals. These descriptions can be combined in Figure 3.ways that produce set theoretical combination of their underlying sets (or that change the only non-atomic object property expressions inset of conditions which must be true of an instance of the combined expression). OWL 1.1 are inverse property expressions.contains the grammar for object property expressions is as follows: inverseObjectProperty := 'InverseObjectProperty' '(' objectPropertyExpression ')' objectPropertyExpression := objectPropertyURI | inverseObjectPropertystandard boolean connectives, and (objectIntersectionOf), not (objectComplementOf), and or (objectUnionOf).

The propositional connectives are presented in Figure 4;3. The only typedescription construct objectUnionOf forms a disjunction of data property expressions are, however, data properties. The grammar for data property expressionsa set of descriptions, objectIntersectionOf is as follows: dataPropertyExpression := dataPropertyURI Figure 4. Data Property Expressions 4.3 Data Ranges Editor's Note: See Issue-5 (n-ary datatypes), Issue-25 (values-class), Issue-29 (owl:DataRange), Issue-31 (XSD defined datatypes), Issue-53 (Linear inequality between two data types), Issue-71 (datarange language range) and Issue-74 (XSD URIs for facets). OWL 1.1 provides several ways to definea range over data values, as shown in Figure 5.conjunction of a datatypeset of descriptions, objectComplementOf is a fundamental typenegation of data range that is defined bya URI. Each datatype URIdescription, and objectOneOf is associated witha predefined arity (notedescrption that contains exactly the same datatype URI cannot be used with different arities).objects denoted by the listset of the datatypes supported in OWL 1.1 is given in [specified individuals.

5.1.1 Syntax

5.1.2 Example

5.2 Object Value Restrictions

OWL 1.1 Semantics ]; furthermore, this list canalso allows descriptions to be extendeddefined by implementations as needed. The meaningmeans of restrictions on object properties, as shown in Figure 4.

The construct objectAllValuesFrom denotes the set of objects that are allowedconnected via the given object property only to signal an error in this case. Complex data ranges can be constructed frominstances of the simpler ones usinggiven description, objectSomeValuesFrom denotes the dataComplementOf constructor, which takes a data range and returns its complement (withset of objects that are connected via the same arity), Furthermore, data ranges (of arity one) consisting exactlygiven object property to at least one instance of the specifiedgiven description, objectExistsSelf denotes the set of constants can be formed usingobjects that are connected to themselves via the dataOneOf constructor.given object property, and objectHasValue denotes the set of objects that are connected via the given object property to the object denoted by the given individual.

Finally, OWL 1.1 descriptions can be defined by restricting the datatypeRestriction constructor creates a data rangecardinality of associations between objects, as shown in Figure 5.

Cardinality restrictions can be qualified or more facet restriction to a particular data range.unqualified, depending on whether there is a facetrestriction consistson the description of a constantthe connected individual; an unqualified cardinality restriction value and a facet type thatis appliedequivalent to a qualified one where the data range in question.restricting description is owl:Thing. The following facet typesconstruct objectMinCardinality denotes the set of objects that are supported in OWL 1.1: length , minLength , maxLength , pattern , minInclusive , minExclusive , maxInclusive , maxExclusive , totalDigits , and fractionDigits .connected via the semanticsgiven object property to at least the given number of instances of the facets is defined ingiven description, the XML Schema Datatypes Specification [ XML Schema Datatypes ]. Review comment from MikeSmith 06:44, 26 November 2007 (EST) Text addressing ISSUE-31 : "Canonical URI for externally defined datatypes" is provided onconstruct objectMaxCardinality denotes the discussion pageset of objects that are connected via the given object property to at most the given number of instances of the given description, and proposed for inclusion here. Figure 5. Data Rangesthe description objectExactCardinality denotes the set of OWL 1.1objects that are connected via the grammar for OWL 1.1 data ranges is as follows: dataComplementOfgiven object property to exactly the given number of instances of the given description.

5.2.1 Syntax

5.2.2 Example

5.3 Data Value Restrictions

OWL 1.1 provides entity annotationsalso allows for this purpose; their structure isthe definition of descriptions by stating restrictions on data properties, as shown in Figure 6.

The notable distinction with respect to object property restrictions is that an entity annotation axiom provides for two typesdataAllValuesFrom and dataSomeValuesFrom restrictions take a list of annotation -- one for the axiom itselfdata property expressions, and one for the entity. Itnot just a single property expression. This is importantin order to distinguish thesesupport descriptions such as "objects whose width is greater than their height", where the values of width and height are specified using two typesdata properties. In such definitions, the arity of annotation:the first one refersgiven data range must be equal to the axiom (e.g., says who has asserted it), whereasnumber of the second one refers togiven data properties.

Figure 7 shows the entity itself (e.g., provides a human-friendly label).restrictions that can be built by stating cardinality restrictions on data properties. The grammar for entity annotations is as follows: annotationsForAxiom := annotation annotationsForEntity := annotation entityAnnotationarity of data range must be one.

5.3.1 Syntax

5.3.2 Example

5.4 Unified Grammar for Expressions

The entityAnnotation nonterminal requires an entity and not a URI. Thus, an OWL class should be annotated as follows: EntityAnnotation(OWLClass(Person) Comment("The set offollowing grammar production integrates all humans.")) This is so that the type of the entity being annotated can easily be determined from the syntactic formtypes of the entity annotation axiom. 5descriptions Editor's Note: See Issue-65 (excess vocab).in OWL 1.1 provides an expressive language for forming descriptions. For clarity, these are presented in three separate diagrams. The propositional connectives are presented in Figure 7. The1.1:

6 Object Property Expressions

Object properties can be combined into more complex expressions, as show in Figure 8.

The objects denoted byonly non-atomic object property expressions in OWL 1.1 are inverse property expressions.

For symmetry, OWL 1.1 also allows for data property expressions, as shown in Figure 9; the setonly type of specified individuals.data property expressions are, however, data properties. The grammar for the propositional description constructsdata property expressions is definedas follows:

6.1 Syntax

6.2 Example

7 Data Range Expressions

7.1 Facet-Datatype Compatibility

7.2 Syntax

7.3 Example

8 Axioms

This section lists the types of axiom that can be stated in OWL 1.1. To make the presentation easier to follow, the axioms are grouped by type.As already mentioned, an axiom may contain an arbitrary number of annotations; furthermore, although annotations do not affect the semantics of an axiom, they are taken into account in the definition of structural equivalence.

6.18.1 Class or DescriptionAxioms

Editor's Note: Need to replace "descriptions" with "expressions" methinks.

The class or descriptionaxioms of OWL 1.1 are shown in Figure 12.11.

The subClassOf axiom states that one description is a subclass of another description. The equivalentClasses axiom takes a set of descriptions and states that they are all equivalent. The disjointClasses axiom takes a set of descriptions and states that all descriptions from the set are pair-wise disjoint. Finally, the disjointUnion axiom defines a class as a union of descriptions, all of which are pair-wise disjoint.

The grammar for the class or description axioms of OWL 1.1 is as follows.8.1.1 Syntax

Figure 12. The Class Axioms of OWL 1.1 6.28.1.2 Example

8.2 Object Property Axioms

8.2.1 Syntax

Editor's Note: I'm unsure what to do with the unifying grammar fragments

8.2.2 Example

8.3 Data Property Axioms

8.3.1 Syntax

Editor's Note: I'm unsure what to do with the unifying grammar fragments

The following grammar production merges all productions for data property axioms:

8.3.2 Example

8.4 Facts

8.4.1 Syntax

Figure 14. Axioms Defining Characteristics8.4.2 Example

9 Annotations

Ontologies can contain information which does not affect the logical meaning of Object Properties,the ontology (or any part IIthereof). Some such information is entirely implicit from the following grammar production merges all productionsOWL point of view: for object property axioms: objectPropertyAxiom := subObjectPropertyOf | equivalentObjectProperties | disjointObjectProperties | inverseObjectProperties | objectPropertyDomain | objectPropertyRange | functionalObjectProperty | inverseFunctionalObjectProperty | reflexiveObjectProperty | irreflexiveObjectProperty | symetricObjectProperty | asymetricObjectProperty | transitiveObjectProperty 6.3 Data Propertyexample, a user may want to physically group axioms Editor's Note: See Issue-8 (dataproperty chains). Data propertytogether which "go together" in some way; however, since an OWL ontology contains a set of axioms, this grouping has no logical significance and certain tools (including structure oriented OWL editors) may ignore it. Similarly, certain serializations may have a comment facility (e.g., RDF/XML and the OWL XML serializations both support XML comments) which is not preserved at the structural level. Users who use these serialization specific mechanisms must take care when manipulating their ontologies using structure oriented tools and, in general, such use is not recommended.

One could use OWL entities and axioms which are similarnot intended to model the subject domain, but, instead, to provide extra-modeling information. For example, it is common to use the Dublin Core vocabulary to represent who originally coined ("created") a class. One could represent this information, using punning, at the logical level. However, this mixes domain modeling with ontology record keeping which can make the ontology more difficult to understand and use.

To solve the problems with these alternatives, OWL 1.1 provides an annotation system which allows users to object property axioms,associate information with entities, ontologies, and are shownaxioms in Figure 15. Note thata structurally significant way which, nevertheless, does not affect the aritylogical meaning of the data range used in a dataPropertyRangeontology. For example, the axiom

is not structurally equivalent to the axiomsaxiom

even though the following grammar production merges all productions for data property axioms: dataPropertyAxiom := subDataPropertyOf | equivalentDataProperties | disjointDataProperties | dataPropertyDomain | dataPropertyRange | functionalDataProperty 6.4 Facts Editor's Note: See Issue-3 (anonymous individuals) and Issue-23 (scoped-names). OWL 1.1 supports a rich setsemantics of axioms for stating facts. Figure 16 showsthe facts thattwo axioms are equivalent.

Annotations can be stated about individuals and descriptions. The sameIndividual axiom states that eachthought as a form of the individuals fromexpression which may be inserted into axioms or appear in ontology structures. To associate an annotation expression with an entity, one uses a given set denotes the same object, whereas the differentIndividuals axiom statesspecial kind of axiom. An annotation consists of an annotation property that eachspecifies the type of the individuals from a given set denotesannotation and a different object.value for the classAssertion axiom statesannotation. OWL 1.1 allows for two kinds of annotation values, as shown in Figure 18.

• Annotation values can be constants. Note that the object denoted by the given individual isthese need not be just strings; rather, any OWL 1.1 constant can be used. For example, one can create an instance ofannotation whose value is a URI formatted according to the given description.XML Schema xsd:anyURI type specification.
• Annotation values can be ontology entities. Such annotations make it clearer that the grammar for these axiomsvalue is as follows: sameIndividualnot just some constant, but an entity from this or some other ontology.

9.1 Syntax

9.2 Entity Annotations

9.3 Built-in Annotation Properties

Annotation properties with the common URIs rdfs:label and is shownrdfs:comment are abbreviated as follows:

OWL 1.1 provides several well-known ontology annotations. These have no meaning in Figure 18.the dataPropertyAssertion states thatmodel-theoretic semantics; however, they may be used by software to manage ontology version.

• An owl:priorVersion annotation can have an individual as a value. The valueURI of a data property forthis individual points to the prior version of the containing ontology.

• An object denoted byowl:backwardCompatibleWith annotation can have an individual as a value. The givenURI of this individual points to the prior version of the containing ontology, and that prior version is compatible with this ontology.

• An owl:incompatibleWith annotation can have an individual is the given constant, whereasas a value. The negativeDataPropertyAssertion statesURI of this individual points to the opposite.prior version of the grammarcontaining ontology, and that prior version is as follows: targetValue := constant dataPropertyAssertion := 'DataPropertyAssertion' '(' { annotation } dataPropertyExpression sourceIndividualURI targetValue ')' negativeDataPropertyAssertion := 'NegativeDataPropertyAssertion' '(' { annotation } dataPropertyExpression sourceIndividualURI targetValue ')' Figure 18. Data Property Assertions The following production integrates all types of facts: fact := sameIndividual | differentIndividuals | classAssertion | objectPropertyAssertion | negativeObjectPropertyAssertion | dataPropertyAssertion | negativeDataPropertyAssertion 7incompatible with this ontology.

10 Nonstructural Restrictions on Axioms