Copyright ©2002 W3C © ( MIT, INRIA, Keio). All Rights Reserved. W3C liability, trademark , document use and software licensing rules apply.
The description of OWL here 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 in DAML+OIL), again for ease of readability. 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.
This syntax does not have to worry about any of the problems induced by the RDF triple model, including non-closed and ill-formed lists and restrictions. No parsetype extensions are needed for readability, and many issues of coordination with the RDF Core WG are not relevant at this level of syntax. Layering issues can also be safely ignored. Further, namespace issues can also be somewhat ignored; in the syntax here reserved words are not given with any namespace qualification.
The abstract syntax is specified here by means of a version of Extended BNF. In this version of BNF, terminals are not quoted, non-terminals are enclosed in pointy brackets (<…>), and alternatives are either separated by vertical bars (|) or are given in different productions. Elements that can occur at most once are enclosed in square brackets ([…]); elements that can occur any number of times (including zero) are enclosed in braces ({…}).
The meaning of each construct in the OWL 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 (and DAML+OIL) 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 target that is approachable to a wider audience, a smaller language has been defined, now referred to as OWL Lite [OWL Features]. This smaller language attempts to capture many of the commonly used features of OWL. It also attempts to describe a useful language that provides more than RDF Schema with the goal of adding functionality that is important in order to support web applications. An abstract syntax is expressed both for this smaller language and also for a fuller style of OWL.
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 restrictions required to make OWL fit into the Description Logic paradigm, and thus this abstract syntax should be thought of a syntax for OWL/DL as defined in Section 5.3.1.
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 non-logical annotations that can be used to record authorship, and other non-logical information associated with an ontology. OWL ontologies are web documents, and can be referenced by means of a URI.
<ontology> ::= Ontology ( {<directive>} )
<directive> ::= Annotation ( <URI reference> <URI reference> )
<directive> ::= Annotation ( <URI reference> <lexical-form> )
<directive> ::= Imports ( <URI> )
<directive> ::= <axiom>
<directive> ::= <fact>
Ontologies incorporate information about classes, properties, and individuals, each of which can have an ID which is a URI reference. (It is convenient to use QNames wherever possible, turning their expansion into a URI reference, as is done in RDF.) Ontologies can also reference built-in XML Schema datatypes, by means of a URI reference for the datatype.
<datatypeID> ::= <URI reference> <classID> ::= <URI reference> <individualID> ::= <URI reference> <datavaluedPropertyID> ::= <URI reference> <individualvaluedPropertyID> ::= <URI reference>
If a URI reference is a datatype, i.e., if there is a datatype definition retrievable using the URI reference, then that URI reference cannot be used as the ID for a class. However, a URI reference can be the ID of a class or datatype as well as the ID of a property as well as the ID of an individual. Individual IDs are used to refer to resources, and typed data literals are used to refer to the XML Schema data values.
In OWL a datatype denotes the set of XML Schema 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. Elements of the first group of properties relate individuals to data values, elements of the second group relate individuals to other individuals.
There are two built-in classes in OWL, they both use URI references in the as-yet-to-be-determined OWL URI, for which the namespace name owl is used here. The class with ID owl:Thing is the class of all individuals, and is part of OWL Lite. The class with ID owl:Nothing is the empty class.
Many OWL constructs use annotations, which, just like annotation directives, are used to record non-logical information associated with some portion of the construct.
<annotation> ::= annotation ( <URI reference> <URI reference> ) <annotation> ::= annotation ( <URI reference> <lexical-form> )
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 the normal RDF/XML syntax.
<fact> ::= <individual>
<individual> ::= Individual( [<individualID>] {<annotation>}
{type(<type>)} {<propertyValue>} )
<propertyValue> ::= value( <individualvaluedPropertyID> <individualID> )
| value( <individualvaluedPropertyID> <individual> )
| value( <datavaluedPropertyID> <dataLiteral> )
Facts are the same in OWL Lite and the full abstract syntax, except for what can be a type. In OWL Lite, types can be classIDs or OWL Lite restrictions
<type> ::= <classID>
| <restriction>
In the full abstract syntax types can be general descriptions, which include classIDs and OWL Lite restrictions
<type> ::= <description>
In the abstract syntax data literals consist of a datatype and the lexical representation of a data value in that datatype (a typed data literal).
<dataLiteral> ::= <typedDataLiteral> <typedDataLiteral> ::= <datatypeID> <lexical-form>
In the abstract syntax the other kinds of facts are used to make individual IDs be the same or pairwise distinct.
<fact> ::= SameIndividual( <individualID> {<individualID>} )
<fact> ::= DifferentIndividuals( <individualID> {<individualID>} )
The biggest differences between OWL Lite and the full abstract syntax 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, and then the full abstract syntax is given as additions to OWL Lite.
Axioms are used to associate class and property IDs 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 full 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 the same 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 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) ID 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 classes are the same.
<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 objects 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> ::= 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 verb, just as in RDF. 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 the property. 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 functional, 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 the same, or make one property be a sub-property of another.
<axiom> ::= EquivalentProperties( <datavaluedPropertyID> {<datavaluedPropertyID>} )
<axiom> ::= SubPropertyOf( <datavaluedPropertyID> <datavaluedPropertyID> )
<axiom> ::= EquivalentProperties( <individualvaluedPropertyID> {<individualvaluedPropertyID>} )
<axiom> ::= SubPropertyOf( <individualvaluedPropertyID> <individualvaluedPropertyID> )
The full 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 full 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 full abstract syntax it is possible to require that a collection of descriptions be pairwise disjoint, or have the same members, or that one description is a subclass of another. Note that the last two of these axioms generalize the first kind of class axiom just above.
<axiom> ::= DisjointClasses( <description> {<description>} )
<axiom> ::= EquivalentClasses( <description> {<description>} )
<axiom> ::= SubClassOf( <description> <description> )
Descriptions in the full abstract syntax include class IDs 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 full 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 full 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> ::= 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 full abstract syntax, is either a datatype or a set of data values.
<dataRange> ::= <datatypeID>
<dataRange> ::= oneOf({<typedDataLiteral>} )
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 full 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] )
<axiom> ::= ObjectProperty
( <individualvaluedPropertyID> {<annotation>} {super(<individualvaluedPropertyID>)}
{domain(<description>)} {range(<description>)}
[inverseOf(<individualvaluedPropertyID>)] [Symmetric]
[Functional | InverseFunctional | Functional InverseFunctional | Transitive] )