Web Ontology Language (OWL) Abstract Syntax and Semantics
Section 2. Abstract Syntax

2. Abstract Syntax

The syntax for OWL in this section abstracts from exchange syntax for OWL and thus facilitates access to and evaluation of the language. This particular syntax has a frame-like style, where a collection of information about a class or property is given in one large syntactic construct, instead of being divided into a number of atomic chunks (as in most Description Logics) or even being divided into even more triples (as when writing OWL as RDF graphs [RDF Concepts]). The syntax used here is rather informal, even for an abstract syntax - in general the arguments of a construct should be considered to be unordered wherever the order would not affect the meaning of the construct.

The abstract syntax is specified here by means of a version of Extended BNF, very similar to the EBNF notation used for XML [XML]. Terminals are quoted; non-terminals are bold and not quoted. Alternatives are either separated by vertical bars (|) or are given in different productions. Components that can occur at most once are enclosed in square brackets ([…]); components that can occur any number of times (including zero) are enclosed in braces ({…}). Whitespace is ignored in the productions here.

Names in the abstract syntax are RDF URI references, [RDF Concepts]. Often these names will be abbreviated into qualified names, using one of the following namespace names:

The meaning of each construct in the abstract syntax is informally described when it is introduced. The formal meaning of these constructs is given in Section 3 via a model-theoretic semantics.

While it is widely appreciated that all of the features in expressive languages such as OWL are important to some users, it is also understood that such languages may be daunting to some groups who are trying to support a tool suite for the entire language. In order to provide a simpler target for implementation, a smaller language has been defined, called OWL Lite [OWL Features]. This smaller language was designed to provide functionality that is important in order to support Web applications, but that is missing in RDF Schema [RDF Schema]. (Note, however, that both OWL DL and OWL Lite do not provide all of the feature of RDF Schema.) The abstract syntax is expressed both for this smaller language, called the OWL Lite abstract syntax here, and also for a fuller style of OWL, called the OWL DL abstract syntax here.

The abstract syntax here is less general than the exchange syntax for OWL. In particular, it does not permit the construction of self-referential syntactic constructs. It is also intended for use in cases where classes, properties, and individuals form disjoint collections. These are roughly the limitations required to make reasoning in OWL be decidable, and thus this abstract syntax should be thought of a syntax for OWL DL.

OWL uses some of the facilities of XML Schema [XML Schema Datatypes]. The following XML Schema datatypes can be used in OWL by means of the XML Schema canonical URI reference for the datatype, http://www.w3.org/2001/XMLSchema#name, where name is the local name of the datatype: xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary, xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name, xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte and xsd:positiveInteger. OWL also uses rdfs:Literal and can use rdf:XMLLiteral. OWL tools need only implement the datatypes xsd:integer and xsd:string.

The other built-in XML Schema datatypes are problematic for OWL, and should not be used:

xsd:duration,

In the current version of XML Schema no equality function is defined for xsd:duration. This may give surprising results when combined with OWL cardinality restrictions. Later revisions of XML Schema datatypes are expected to provide such a function, in which case the revised duration datatype would be fully appropriate for use with OWL.

xsd:QName, xsd:ENTITY,

These datatypes require an enclosing XML document context, which may not be available in a specific application scenario for an OWL ontology.

xsd:NOTATION,

This datatype is intended for use as a base type for user defined datatypes.

xsd:ID, xsd:IDREF,

ID and IDREF are for cross references within an XML document and thus are not useful in OWL.

xsd:IDREFS, xsd:ENTITIES, xsd:NMTOKENS,

Sequence-valued datatypes are not used in OWL.

2.1. Ontologies

An OWL ontology in the abstract syntax contains a sequence of axioms and facts. OWL ontologies can have a name. OWL ontologies can also have annotations that can be used to record authorship and other information associated with an ontology, including imports references to other ontologies.

ontology ::= 'Ontology(' [ ontologyID ] { directive } ')'
directive ::= 'Annotation(' ontologyPropertyID ontologyID ')'
	 | 'Annotation(' annotationPropertyID URIreference ')'
         | 'Annotation(' annotationPropertyID dataLiteral ')'
         | 'Annotation(' annotationPropertyID individual ')'
         | axiom
         | fact

Names of ontologies are used in the abstract syntax to carry the meaning associated with publishing an ontology on the Web. The name of an ontology is thus the URI where it would be found. Imports annotations, in effect, are directives to retrieve a Web document and treat it as an OWL ontology. However, most aspects of the Web, including missing, unavailable, and time-varying documents, reside outside the OWL specification; all that is carried here is that a URI can be ``dereferenced'' into an OWL ontology. In several places in this document, therefore, idealizations of this operational meaning for imports are used.

Ontologies incorporate information about classes, properties, and individuals, each of which can have an identifier which is a URI reference. Some of these identifiers need to be given axioms, as detailed in Section 2.3.

datatypeID ::= URIreference
classID ::= URIreference
individualID ::= URIreference
ontologyID ::= URIreference
datavaluedPropertyID ::= URIreference
individualvaluedPropertyID ::= URIreference
annotationPropertyID ::= URIreference
ontologyPropertyID ::= owl:imports | owl:priorVersion | owl:backwardCompatibleWith | owl:incompatibleWith

A URI reference cannot be both a datatypeID and a classID in an ontology. A URI reference also cannot be more than one of an datavaluedPropertyID, an individualvaluedPropertyID, an annotationPropertyID, or an ontologyPropertyID in an ontology. However, a URI reference can be the identifier of a class or datatype as well as the identifier of a property as well as the identifier of an individual, although the ontology cannot then be translated into an OWL DL RDF graph.

In OWL, as in RDF, a datatype denotes the set of data values that is the value space for the datatype. Classes denote sets of individuals. Properties relate individuals to other information, and are divided into four disjoint groups, data-valued properties, individual-valued properties, annotation properties, and ontology properties. Data-valued properties relate individuals to data values. Individual-valued properties relate individuals to other individuals. Annotation properties are used to place annotations on individuals, class names, property names, and ontology names. Ontology properties relate ontologies to other ontologies, in particular being used for importing information from other ontologies. Individual identifiers are used to refer to resources, and data literals are used to refer to data values.

There are two built-in classes in OWL, they both use URI references in the OWL namespace, i.e., names starting with http://www.w3.org/2002/07/owl#, for which the namespace name owl is used here. (Throughout this document qualified names will be used as abbreviations for URI references.) The class with identifier owl:Thing is the class of all individuals, and is part of OWL Lite. The class with identifier owl:Nothing is the empty class.

There are several built-in annotation properties in OWL, namely owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, and rdfs:isDefinedBy. In keeping with their definition in RDF, rdfs:label and rdfs:comment can only be used with data literals.

All ontology properties are built-in; they are owl:imports, owl:priorVersion, owl:backwardCompatibleWith, and owl:incompatibleWith. Ontology annotations that use owl:imports have the extra effect of importing the target ontology.

Many OWL constructs use annotations, which, just like annotation directives, are used to record information associated with some portion of the construct.

annotation ::= 'annotation(' annotationPropertyID URIreference ')'
            | 'annotation(' annotationPropertyID dataLiteral ')'
            | 'annotation(' annotationPropertyID individual ')'

2.2. Facts

There are two kinds of facts in the OWL abstract syntax.

The first kind of fact states information about a particular individual, in the form of classes that the individual belongs to plus properties and values of that individual. An individual can be given an individualID that will denote that individual, and can be used to refer to that individual. However, an individual need not be given an individualID; such individuals are anonymous (blank in RDF terms) and cannot be directly referred to elsewhere. The syntax here is set up to somewhat mirror RDF/XML syntax [RDF Syntax] without the use of rdf:nodeID.

fact ::= individual 
individual ::= 'Individual(' [ individualID ] { annotation } { 'type(' type ')' } { value } ')'
value ::= 'value(' individualvaluedPropertyID individualID ')'
        | 'value(' individualvaluedPropertyID  individual ')'
        | 'value(' datavaluedPropertyID  dataLiteral ')'

Facts are the same in the OWL Lite and OWL DL abstract syntaxes, except for what can be a type. In OWL Lite, types can be class IDs or OWL Lite restrictions, see Section 2.3.1.2

type ::= classID
       | restriction

In the OWL DL abstract syntax types can be general descriptions, which include class IDs and OWL Lite restrictions as well as other constructs

type ::= description

Data literals in the abstract syntax are either plain literals or typed literals. Plain literals consist of a Unicode string in Normal Form C and an optional language tag, as in RDF plain literals [RDF Concepts]. Typed literals consist of a lexical representation and a URI reference, as in RDF typed literals [RDF Concepts], but without the optional language tag.

dataLiteral ::= typedLiteral | untypedLiteral
typedLiteral ::= lexicalForm^^URIReference
untypedLiteral ::= lexicalForm | lexicalForm@languageTag
lexicalForm ::= as in RDF, a unicode string in normal form C
languageTag ::= as in RDF, an XML language tag

The second kind of fact is used to make individual identifiers be the same or pairwise distinct.

fact ::= 'SameIndividual(' individualID individualID {individualID} ')'
      | 'DifferentIndividuals(' individualID individualID {individualID} ')'

2.3. Axioms

The biggest differences between the OWL Lite and OWL DL abstract syntaxes show up in the axioms, which are used to provide information about classes and properties. As it is the smaller language, OWL Lite axioms are given first, in Section 2.3.1. The OWL DL axioms are given in Section 2.3.2. OWL DL axioms include OWL Lite axioms as special cases.

Axioms are used to associate class and property identifiers with either partial or complete specifications of their characteristics, and to give other information about classes and properties. Axioms used to be called definitions, but they are not all definitions in the common sense of the term, as has been made evident in several discussions in the WG, and thus a more-neutral name has been chosen.

The syntax used here is meant to look somewhat like the syntax used in some frame systems. Each class axiom in OWL Lite contains a collection of more-general classes and a collection of local property restrictions in the form of restriction constructs. The restriction construct gives the local range of a property, how many values are permitted, and/or a collection of required values. The class is made either equivalent to or a subset of the intersection of these more-general classes and restrictions. In the OWL DL abstract syntax a class axiom contains a collection of descriptions, which can be more-general classes, restrictions, sets of individuals, and boolean combinations of descriptions. Classes can also be specified by enumeration or be made equivalent or disjoint.

Properties can be equivalent to or sub-properties of others; can be made functional, inverse functional, symmetric, or transitive; and can be given global domains and ranges. However, most information about properties is more naturally expressed in restrictions, which allow local range and cardinality information to be specified.

URI references used as class IDs or datatype IDs have to be differentiated, and so need an axiom, except for the built-in OWL classes and datatypes and rdfs:Literal. There can be more than one axiom for a class or datatype. Properties used in an abstract syntax ontology have to be categorized as either data-valued or individual-valued or annotation properties. Properties thus also need an axiom for this purpose, at least. If an ontology imports another ontology, the axioms in the imported ontology (and any ontologies it imports, and so on) can be used for these purposes.

2.3.1. OWL Lite Axioms

2.3.1.1. OWL Lite Class Axioms

In OWL Lite class axioms are used to state that a class is exactly equivalent to, for the modality complete, or a subclass of, for the modality partial, the conjunction of a collection of superclasses and OWL Lite Restrictions. It is also possible to indicate that the use of a class is deprecated.

axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { super } ')'
modality ::= 'complete' | 'partial'
super ::= classID | restriction

In OWL Lite it is possible to state that two or more classes are equivalent.

axiom ::= 'EquivalentClasses(' classID classID { classID } ')'

Datatype axioms are simpler, only serving to say that a datatype ID is the ID of a datatype and to give annotations for the datatype.

axiom ::= 'Datatype(' datatypeID ['Deprecated']  { annotation } )'

2.3.1.2. OWL Lite Restrictions

Restrictions are used in OWL Lite class axioms to provide local constraints on properties in the class. Each allValuesFrom part of a restriction makes the constraint that all values of the property for individuals in the class must belong to the specified class or datatype. Each someValuesFrom part makes the constraint that there must be at least one value for the property that belongs to the specified class or datatype. The cardinality part says how many distinct values there are for the property for each individual in the class. In OWL Lite the only cardinalities allowed are 0 and 1.

See Section 2.3.1.3 for a limitation on which properties can have cardinality parts in restrictions.

restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent ')'
            | 'restriction(' individualvaluedPropertyID objectRestrictionComponent ')'
dataRestrictionComponent ::= 'allValuesFrom(' datatypeID ')'
            | 'someValuesFrom(' datatypeID ')'
            | cardinality
objectRestrictionComponent ::= 'allValuesFrom(' classID ')'
            | 'someValuesFrom(' classID ')'
            | cardinality 
cardinality ::= 'minCardinality(0)' | 'minCardinality(1)' |
            | 'maxCardinality(0)' | 'maxCardinality(1)' |
            | 'cardinality(0)'    | 'cardinality(1)'

2.3.1.3. OWL Lite Property Axioms

Properties are also specified using a frame-like syntax. Data-valued properties relate individuals to data values, like integers. Individual-valued properties relate individuals to other individuals. These two kinds of properties can be given super-properties, allowing the construction of a property hierarchy. It does not make sense to have an individual-valued property be a super-property of a data-valued property, or vice versa. Data-valued and individual-valued properties can also be given domains and ranges. A domain for a property specifies which individuals are potential subjects of statements that have the property as predicate, just as in RDFS. In OWL Lite the domains of properties are classes. There can be multiple domains, in which case only individuals that belong to all of the domains are potential subjects. A range for a property specifies which individuals or data values can be objects of statements that have the property as predicate. Again, there can be multiple ranges, in which case only individuals or data values that belong to all of the ranges are potential objects. In OWL Lite ranges for individual-valued properties are classes; ranges for data-valued properties are datatypes.

Data-valued properties can be specified as (partial) functional, i.e., given an individual, there can be at most one relationship to a data value for that individual in the property. Individual-valued properties can be specified to be the inverse of another property. Individual-valued properties can also be specified to be symmetric as well as partial functional, partial inverse-functional, or transitive.

To preserve decidability of reasoning in OWL Lite, not all properties can have cardinality restrictions placed on them or be specified as functional or inverse-functional. An object property is complex if 1/ it is specified as being functional or inverse-functional, 2/ there is some cardinality restriction that uses it, 3/ it has an inverse that is complex, or 4/ it has a super-property that is complex. Complex properties cannot be specified as being transitive.

axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation } 
              { 'super(' datavaluedPropertyID ')' } ['Functional'] 
              { 'domain(' classID' ')' } { 'range(' datatypeID ')' } ')'
       | 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation } 
              { 'super(' individualvaluedPropertyID ')' }
              { 'domain(' classID ')' } { 'range(' classID ')' } 
              [ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ] 
              [ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ] ')'
       | 'AnnotationProperty(' annotationPropertyID { annotation } ')'

The following axioms make several properties be equivalent, or make one property be a sub-property of another.

axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID  { datavaluedPropertyID } ')'
        | 'SubPropertyOf(' datavaluedPropertyID  datavaluedPropertyID ')'
        | 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID  { individualvaluedPropertyID } ')'
        | 'SubPropertyOf(' individualvaluedPropertyID  individualvaluedPropertyID ')'

2.3.2. OWL DL Axioms

2.3.2.1. OWL DL Class Axioms

The OWL DL abstract syntax has more-general versions of the OWL Lite class axioms where superclasses, more-general restrictions, and boolean combinations of these are allowed. Together, these constructs are called descriptions.

axiom ::= 'Class(' classID  ['Deprecated'] modality { annotation } { description } ')'
modality ::= 'complete' | 'partial'

In the OWL DL abstract syntax it is also possible to make a class exactly consist of a certain set of individuals, as follows.

axiom ::= 'EnumeratedClass(' classID ['Deprecated'] { annotation } { individualID } ')'

Finally, in the OWL DL abstract syntax it is possible to require that a collection of descriptions be pairwise disjoint, or have the same instances, or that one description is a subclass of another. Note that the last two of these axioms generalize, except for lack of annotation, the first kind of class axiom just above.

axiom ::= 'DisjointClasses(' description description { description } ')'
        | 'EquivalentClasses(' description { description } ')'
        | 'SubClassOf(' description description ')'

Datatype axioms are the same as in OWL Lite.

axiom ::= 'Datatype(' datatypeID ['Deprecated']  { annotation } )'

2.3.2.2. OWL DL Descriptions

Descriptions in the OWL DL abstract syntax include class identifiers and the restriction constructor. Descriptions can also be boolean combinations of other descriptions, and sets of individuals.

description ::= classID
            | restriction
            | 'unionOf(' { description } ')'
            | 'intersectionOf(' { description } ')'
            | 'complementOf(' description ')'
            | 'oneOf(' { individualID } ')'

2.3.2.3. OWL DL Restrictions

Restrictions in the OWL DL abstract syntax generalize OWL Lite restrictions by allowing descriptions where classes are allowed in OWL Lite and allowing sets of data values as well as datatypes. The combination of datatypes and sets of data values is called a data range. In the OWL DL abstract syntax, values can also be given for properties in classes. As well, cardinalities are not restricted to only 0 and 1.

restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent { dataRestrictionComponent } ')'
            | 'restriction(' individualvaluedPropertyID objectRestrictionComponent { objectRestrictionComponent } ')'
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
            | 'someValuesFrom(' dataRange ')'
            | 'value(' dataLiteral ')'
            | cardinality
objectRestrictionComponent ::= 'allValuesFrom(' description ')'
            | 'someValuesFrom(' description ')'
            | 'value(' individualID ')'
            | cardinality 
cardinality ::= 'minCardinality(' non-negative-integer ')'
            | 'maxCardinality(' non-negative-integer ')'
            | 'cardinality(' non-negative-integer ')'

A data range, used as the range of a data-valued property and in other places in the OWL DL abstract syntax, is either a datatype or a set of data values.

dataRange ::= datatypeID
            | 'oneOf(' { dataLiteral } ')'

The OWL Lite limitations on which properties can have cardinality components in their restrictions are also present in OWL DL.

2.3.2.4. OWL DL Property Axioms

Property axioms in the OWL DL abstract syntax generalize OWL Lite property axioms by allowing descriptions in place of classes and data ranges in place of datatypes in domains and ranges.

axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated']
                { annotation } { 'super(' datavaluedPropertyID ')'} ['Functional']
                { 'domain(' description ')' } { 'range(' dataRange ')' } ')'
        | 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation } 
                { 'super(' individualvaluedPropertyID ')' }
                { 'domain(' description ')' } { 'range(' description ')' } 
                [ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ] 
                [ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ] ')'
        | 'AnnotationProperty(' annotationPropertyID { annotation } ')'

The limitations on which properties can be specified to be functional or inverse-functional is also present in OWL DL.

As in OWL Lite, the following axioms make several properties be equivalent, or make one property be a sub-property of another.

axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID  { datavaluedPropertyID } ')'
        | 'SubPropertyOf(' datavaluedPropertyID  datavaluedPropertyID ')'
        | 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID
                                  { individualvaluedPropertyID } ')'
        | 'SubPropertyOf(' individualvaluedPropertyID  individualvaluedPropertyID ')'