Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
The description of OWL in this Section abstracts from concrete syntax and thus facilitates access to and evaluation of the language. A high-level syntax is used to make the language features easier to see. 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 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.
The meaning of each construct in the abstract syntax is 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 also attempts to describe a useful language that provides more than RDF Schema [RDF Schema] with the goal of adding functionality that is important in order to support web applications. 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 built-in non-list XML Schema datatypes, called the OWL 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. The other built-in XML Schema datatypes may be used, but with caveats (see below).
The specific considerations with the other built-in XML Schema datatypes are:
An OWL ontology in the abstract syntax is a sequence of axioms and facts, plus inclusion references to other ontologies, which are considered to be included in the ontology. Ontologies can also have annotations that can be used to record authorship and other information associated with an ontology. OWL ontologies are web documents, and can be referenced by means of a URI.
ontology ::= 'Ontology(' { directive } ')'
directive ::= 'Annotation(' URIreference URIreference ')'
| 'Annotation(' URIreference dataLiteral ')'
| 'Imports(' URI ')'
| axiom
| fact
Ontologies incorporate information about classes, properties, and individuals, each of which can have an identifier which is a URI reference.
datatypeID ::= URIreference classID ::= URIreference individualID ::= URIreference datavaluedPropertyID ::= URIreference individualvaluedPropertyID ::= URIreference
If a URI reference is a datatype, i.e., the URI reference points to one of the useful XML Schema datatypes described above, then that URI reference cannot be used as the identifier of a class. 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 in this abstract syntax, although the ontology cannot then be translated into an OWL DL RDF graph. Individual identifiers are used to refer to resources, and data literals are used to refer to data values.
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 two disjoint groups, data-valued properties and individual-valued properties. Data-valued properties relate individuals to data values; individual-valued properties relate individuals to other individuals.
There are two built-in classes in OWL, they both use URI references in the OWL URI, http://www.w3.org/2002/07/owl#, for which the namespace name owl is used here. 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.
Many OWL constructs use annotations, which, just like annotation directives, are used to record information associated with some portion of the construct.
annotation ::= 'annotation(' URIreference URIreference ')'
| 'annotation(' URIreference dataLiteral ')'
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 mirror RDF/XML syntax without the use of rdf:nodeID.
fact ::= individual
individual ::= 'Individual(' [ individualID ] { annotation }
{ 'type(' type ')' } { propertyValue } ')'
propertyValue ::= '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 classIDs or OWL Lite restrictions
type ::= classID
| restriction
In the OWL DL abstract syntax types can be general descriptions, which include classIDs and OWL Lite restrictions as well as other constructs
type ::= description
Data literals in the abstract syntax consist of a datatype and the lexical representation of a data value in that datatype (a typed literal) or just a string (an untyped literal). In the abstract syntax typed literals must be valid, i.e., xsd:integer1.5 is not a valid OWL data literal.
dataLiteral ::= typedLiteral | untypedLiteral typedLiteral ::= datatypeID lexicalForm untypedLiteral ::= lexicalForm lexicalForm ::= UniCode string enclosed in quotes
The second kind of facts is used to make individual identifiers be the same or pairwise distinct.
fact ::= 'SameIndividual(' individualID {individualID} ')'
| 'DifferentIndividuals(' individualID {individualID} ')'
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. The OWL DL axioms include the 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 logical 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.
There is no requirement in the abstract syntax that there be an axiom for each class used in an ontology. In fact, there can be any number of axioms for each class, including none. Properties used in an abstract syntax ontology have to be categorized as either data-valued or individual-valued, so they need an axiom for this purpose at least. There is no requirement that there be at most one axiom for a class or property used in an ontology. Each axiom for a particular class (or property) identifier contributes to the meaning of the class (or property).
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.
axiom ::= 'Class(' classID 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 } ')'
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.
There is a side condition in OWL Lite that properties that are transitive or that have transitive sub-properties may not have cardinality conditions expressed on them in restrictions.
restriction ::= 'restriction(' datavaluedPropertyID { 'allValuesFrom(' datatypeID ')'}
{ 'someValuesFrom(' datatypeID ')' } { cardinality } ')'
| 'restriction(' individualvaluedPropertyID { 'allValuesFrom(' classID ')'}
{ 'someValuesFrom(' classID ')' } { cardinality } ')'
cardinality ::= 'minCardinality(0)' | 'minCardinality(1)' |
| 'maxCardinality(0)' | 'maxCardinality(1)' |
| 'cardinality(0)' | 'cardinality(1)'
Properties are also specified using a frame-like syntax. Properties are divided into data-valued properties, which relate individuals to data values, like integers, and individual-valued properties, which relate individuals to other individuals. Properties can be given super-properties, allowing the construction of a property hierarchy. It does not make sense to have an individual property be a super-property of a data property, or vice versa.
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. Properties can have 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, properties can have 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.
Individual-valued properties that are transitive, or that have transitive sub-properties, may not have cardinality conditions expressed on them, either in restrictions or by being functional, or inverse functional. This is needed to maintain the decidability of the language.
axiom ::= 'DatatypeProperty(' datavaluedPropertyID { annotation } { 'super(' datavaluedPropertyID ')' }
{domain(classID')'} {range(datatypeID')' }
[Functional] ')'
axiom ::= 'ObjectProperty(' individualvaluedPropertyID { annotation } { 'super(' individualvaluedPropertyID ')'}
{ 'domain(' classID ')'} { 'range(' classID ')' }
['inverseOf(' individualvaluedPropertyID' )'] [ Symmetric ]
[ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ] ')'
The following axioms make several properties be equivalent, or make one property be a sub-property of another.
axiom ::= 'EquivalentProperties(' datavaluedPropertyID { datavaluedPropertyID } ')'
| 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')'
| 'EquivalentProperties(' individualvaluedPropertyID { individualvaluedPropertyID } ')'
| 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'
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 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 { 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 annotataion, the first kind of class axiom just above.
axiom ::= 'DisjointClasses(' description { description } ')'
| 'EquivalentClasses(' description { description } ')'
| 'SubClassOf(' description description ')'
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 } ')'
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 { 'allValuesFrom(' dataRange ')'}
{ 'someValuesFrom(' dataRange ')'} { 'value(' dataLiteral ')' }
{ cardinality } ')'
| 'restriction(' individualvaluedPropertyID { 'allValuesFrom(' description ')'}
{ 'someValuesFrom(' description ')'} { 'value(' individualID ')' }
{ cardinality } ')'
cardinality ::= 'minCardinality(' non-negative-integer ')'
| 'maxCardinality(' non-negative-integer ')'
| 'cardinality(' non-negative-integer ')'
A dataRange, 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 } ')'
As in OWL Lite, there is a side condition that properties that are transitive, or that have transitive sub-properties, may not have cardinality conditions expressed on them in restrictions.
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 { annotation } { 'super(' datavaluedPropertyID ')'}
{ 'domain(' description ')' } { 'range(' dataRange ')'}
[ 'Functional' ] ')'
| 'ObjectProperty(' individualvaluedPropertyID { annotation } { 'super(' individualvaluedPropertyID ')'}
{ 'domain(' description ')' } { 'range(' description ')' }
[ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ]
[ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ] ')'
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 } ')'
| 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')'
| 'EquivalentProperties(' individualvaluedPropertyID { individualvaluedPropertyID } ')'
| 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'