©2002 Lucent Technologies, Inc. Frank van Harmelen, and Ian Horrocks.
The OWL Web Ontology Language is being designed by the W3C Web Ontology Working Group as a revision of the DAML+OIL web ontology language. This description of OWL is at a high level, ignoring the details of concrete syntax and precise semantics, and in a more user-friendly fashion than the RDF syntax of DAML+OIL.
The W3C Web Ontology Working Group (WebOnt) is tasked with producing a web ontology language extending the reach of XML, RDF, and RDF Schema. This language, called OWL, will be based on the DAML+OIL web ontology language.
A number of problems have been discovered in the design of DAML+OIL, mostly having to do with its relationship with the changes to RDF being undertaken by the W3C RDF Core Working Group. These problems have delayed work on OWL by WebOnt.
This document contains a high-level description of OWL, in the form of an abstract syntax. It is being produced so that WebOnt can continue its work in advance of the resolution of the issues related to the problems in DAML+OIL.
A high-level abstract syntax is used here to make the language features easier to see, as it is more compact than an XML- or RDF-based concrete syntax would be. This particular abstract 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 where the order would not affect the meaning of the construction.
This abstract 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 issues of coordination with the RDF Core WG are not active at this level of syntax. Layering issues can also be safely ignored.
The abstract syntax here can be viewed as an abstract syntax for DAML+OIL. It can easily be transformed into DAML+OIL. The only substantive changes from DAML+OIL are
Readers can safely assume that anything that can be stated in this abstract syntax will end up in OWL, and in a manner maximally compatible with DAML+OIL.
This document has a number of differences from the first version, but stays in the spirit of that version. The major differences are:
Aside from these major differences there are a number of minor differences, including a number of changes to the names of the various constructs. These naming changes may indicate potential changes to the preferred names in the concrete syntax for OWL, but the intent of WebOnt is to maintain the DAML+OIL names to the maximum extent reasonable.
An OWL ontology is a sequence of axioms and facts, plus references to other ontologies, which are considered to be included in the ontology. OWL ontologies are web documents, and can be referenced by means of a URI. Ontologies also have a non-logical component (not yet specified) that can be used to record authorship, and other non-logical information to be associated with a ontology.
An ontology O2 is directly-included in an ontology O1 if O2 is referred to by an "include" directive in O1. An ontology O2 is included in an ontology O1 if it is directly-included in O1 or if there is some ontology O3 such that O3 is directly-included in O1 and O2 is included in O3.
<ontology> ::= Ontology ( [<authorship-etc>] {<directive>} )
<authorship-etc> ::= ...
<directive> ::= <include>
<directive> ::= <axiom>
<directive> ::= <fact>
<include> ::= Include ( < URI > )
Ontologies incorporate information about classes, properties, and individuals, each of which can have an ID which is a qualified name. Ontologies can also reference XML Schema datatypes, by means of a qualified name for the datatype.
<datatypeID> ::= <QName> <classID> ::= <QName> <individualID> ::= <QName> <dataPropertyID> ::= <QName> <individualPropertyID> ::= <QName>
If a qualified name is a datatype, i.e., if there is a datatype definition retrievable using the qualified name, then that qualified name cannot be used as the ID for a class. However, a qualified name 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.
Individuals correspond to RDF resources, and are distinct from data values, which are elements of the value space of XML Schema simple datatypes.
Property IDs are divided into two disjoint groups, data property IDs, and individual property IDs. Element of the first group of properties relate individuals to data values, elements of the second group relate individuals to other individuals.
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. These 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.
Class axioms include the common, widely understood frame idiom. The abstract syntax used here is meant to look somewhat like the syntax used in some frame systems. Each frame-like class axiom contains a collection of more-general classes; a collection of local property restrictions, in the form of restriction constructs; and a collection of descriptions. The restriction construct gives the local range of a property, how many values are permitted, and a collection of required values. Descriptions are used to specify boolean combinations of restrictions and other descriptions as well as construct sets of individuals. Classes can also be specified by enumeration or be made the same or disjoint.
Properties can be the equivalent to or subproperties of others; can be made functional, inverse functional, or transitive; and can be given global domains and ranges. However, most information about properties is more naturally expressed in restrictions, which allow local cardinality and range information to be specified.
The following axiom states that a class is exactly equivalent to the conjunction of a collection of superclasses, property restrictions, and descriptions.
<axiom> ::= EquivalentClass( <classID> {super=<classID>}
{<restriction>} {<description>} )
The next axiom is the same, except that the defined class is an unspecified subclass of the conjunction.
<axiom> ::= SubClass( <classID> {super=<classID>}
{<restriction>} {<description>} )
It is also possible to define a class as a set of individuals, as follows.
<axiom> ::= EnumeratedClass( <classID> {<individualID>} )
Finally, it is possible to require that a collection of descriptions have the same members, or to be pairwise disjoint, or that one description is a subclass of another.
<axiom> ::= DisjointClasses( <description> {<description>} )
<axiom> ::= EquivalentClasses( <description> {<description>} )
<axiom> ::= SubClassOf( <description> <description> )
Properties are also defined using a frame-like syntax, providing superproperties, domains, ranges, and other logical information. Properties are divided into data properties, which relate individuals to data values, like integers, and individual properties, which relate individuals to other individuals.
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, inverse functional, or one-to-one. This is necessary in order to maintain the decidability of the language.
<axiom> ::= DataProperty ( <dataPropertyID> {super=<dataPropertyID>}
{domain=<description>} {range=<dataRange>}
[Functional] )
<axiom> ::= IndividualProperty ( <PropertyID> {super=<individualPropertyID>}
{domain=<description>} {range=<description>}
[inverseOf=<individualPropertyID>] [Symmetric]
[Functional | InverseFunctional | OneToOne | Transitive] )
A dataRange, i.e., the range of a data property, is either a datatype or a set of data values, which consist of a datatype and the lexical representation of a data value in that datatype.
<dataRange> ::= <datatypeID>
<dataRange> ::= OneOf({<dataValue>} )
<dataValue> ::= <datatypeID> <lexical-form>
The following ``axioms'' make several properties be the same, or make one property be a sub-property of another.
<axiom> ::= EquivalentProperties( <dataPropertyID> {<dataPropertyID>} )
<axiom> ::= SubPropertyOf( <dataPropertyID> <dataPropertyID> )
<axiom> ::= EquivalentProperties( <individualPropertyID> {<individualPropertyID>} )
<axiom> ::= SubPropertyOf( <individualPropertyID> <individualPropertyID> )
Restriction constructs place restrictions on properties in classes. The range part means that all fillers must belong to a class or datatype range. Each required part means that there must be at least one filler for the property that belongs to the class or datatype range. Each value part means that the individual or data value must be a filler for the property. The cardinality part says how many fillers there are for the property. Properties that are transitive, or that have transitive sub-properties, may not have cardinality conditions expressed on them in restrictions.
<restriction> ::= restriction( <dataPropertyID> [range=<dataRange>]
{required=<dataRange>} {value=<dataValue>}
[cardinality=<cardinality>] )
<restriction> ::= restriction( <individualPropertyID> [range=<description>]
{required=<description>} {value=<individualID>}
[cardinality=<cardinality>] )
<cardinality> ::= atleast( <positive-integer> )
| atmost( <non-negative-integer> )
| atleast( <positive-integer> ) atmost( <non-negative-integer> )
| exactly( <non-negative-integer> )
Descriptions 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> {<description>} )
| IntersectionOf( <description> {<description>} )
| ComplementOf( <description> )
| OneOf({<individualID>} )
Facts state information about particular individuals in the form of a class that the individual belongs to plus properties and values. Individuals can either be given an individualID or be anonymous (blank nodes in RDF terms). The syntax here is set up to mirror the normal RDF/XML syntax.
<fact> ::= Individual( [<individualID>] {<classID>}
{<propertyValue>} )
<propertyValue> ::= ( <individualPropertyID> <fact> )
| ( <individualPropertyID> <individualID> )
| ( <datapropertyID> <dataValue> )
Facts can be used to make individual IDs denote the same individual, or pairwise-different individuals.
<fact> ::= SameIndividual( <individualID> {<individualID>} )
<fact> ::= DifferentIndividuals( <individualID> {<individualID>} )