Copyright ©2002 W3C ® ( MIT , INRIA , Keio). All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.
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 contains a high-level, abstract syntax for both OWL and OWL Lite, a subset of OWL. This syntax serves as part of a high-level specification for the formalism. A mapping from the abstract syntax to the OWL exchange syntax is also provided.
This is a W3C Web Ontology Working Group Working Draft produced 29 July 2002 as part of the W3C Semantic Web Activity (Activity Statement). It incorporates decisions made by the Working Group in designing the OWL Web Ontology Language.
This document is being released for review by W3C Members and other interested parties to encourage feedback and comments. This is the first version of this document, and there are still many decisions that impact this document that remain to be decided by the Working Group.
There are no patent disclosures related to this work at the time of this writing.
This is a public W3C Working Draft and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
Comments on this document are invited and should be sent to the public mailing list public-webont-comments@w3.org. An archive of comments is available at http://lists.w3.org/Archives/Public/public-webont-comments/ .
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, is based on the DAML+OIL web ontology language [DAML+OIL].
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 [RDFMS]. being undertaken by the W3C RDF Core Working Group.
This document contains a high-level description of the features that will be in OWL, in the form of constructs and informal descriptions of the meaning of these constructs.
This document contains neither a presentation syntax nor an exchange syntax for OWL. An XML presentation syntax may be defined, as an XML schema. The official exchange syntax for OWL is RDF; a document defining how RDF is used to encode OWL is the subject of the OWL Reference document [OWL Reference]. This document also does not contain a formal semantics for OWL, but one will be provided.
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. 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.
The language described here is very close to DAML+OIL. The abstract syntax 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
There are also 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.
This document takes stances on several non-closed working group issues. All working group issues are discussed in the issue listing document [OWL Issues].
This document takes stances on several other points that are not official working group issues.
The description of OWL here abstracts from concrete syntax and thus facilities 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 whereever 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 issues of coordination with the RDF Core WG are not active 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 formal meaning of OWL constructs will be defined elsewhere, but some indications of this meaning are given in this document. The meaning of OWL will be given via a model-theoretic semantics, which will be an extension of the model theory for RDF [RDF MT]. In the OWL model theory there is a domain of discourse, consisting of resources, which is disjoint from the set of XML Schema data values. (The term ``individual'' is used here instead of resource, as RDF resources may also be data values.)
An OWL ontology is a sequence of axioms and facts, plus inclusion 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 associated with a ontology.
<ontology> ::= Ontology ( [<authorship-etc>] {<directive>} )
<authorship-etc> ::= ...
<directive> ::= <imports>
<directive> ::= <axiom>
<directive> ::= <fact>
<imports> ::= imports ( <URI> )
Ontologies incorporate information about classes, properties, and individuals, each of which can have an ID which is URI reference. (It is convenient to use QNames whereever possible, turning their expansion into a URI reference, as is done in RDF.) Ontologies can also reference XML Schema datatypes, by means of a name for the datatype.
<datatypeID> ::= <URI reference> <classID> ::= <URI reference> <individualID> ::= <URI reference> <datavaluedPropertyID> ::= <URI reference> <individualvaluedPropertyID> ::= <URI reference>
If a name is a datatype, i.e., if there is a datatype definition retrievable using the name, then that name cannot be used as the ID for a class. However, a 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. Individual IDs are used to refer to resources, and typed or untyped 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 class IDs in the as-yet-to-be-determined OWL URI, for which the namespace name owl is used here. The class with name owl:Thing is the class of all individuals, and is part of OWL Lite. The class with name owl:Nothing is the empty class.
There are two kinds of facts in OWL. 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>] {type=<classID>}
{<propertyValue>} )
<propertyValue> ::= ( <individualvaluedPropertyID> <individualID> )
| ( <individualvaluedPropertyID> <individual> )
| ( <datavaluedPropertyID> <dataLiteral> )
In this syntax data literals consist either of a datatype and the lexical representation of a data value in that datatype (a typed data literal), or just the lexical representation of a data value (an untyped data literal). Allowing untyped data literals introduces some problems to the formalism, and care has to be taken here. In particular, OneOf only allows typed data literals.
<dataLiteral> ::= <typedDataLiteral> | <untypedDataLiteral> <typedDataLiteral> ::= <datatypeID> <lexical-form> <untypedDataLiteral> ::= <lexical-form>
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>} )
So far OWL and OWL Lite have been the same. The differences between them show up in the axioms, which are used to provide information about classes and properties. As it is the smaller language, the syntax of axioms and facts starts with OWL Lite, and then defines the full OWL syntax 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. 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.
The syntax used here for classes 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 OWL 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 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 range and cardinality information to be specified.
There is no requirement that there be an axiom for each class used in an ontology. Properties used in an 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) name 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> {<classID>} {<restriction>} )
<modality> ::= complete | partial
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 object 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 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( 1 )
| 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 superproperties, allowing the construction of a property hierarchy. Individual properties cannot be superproperties of data properties, and 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., there is at most one relationship for that property between a given individual and a data value. Individual-valued properties can be specified to be the inverse of another property. Individual-valued properties can also be specified to be symmetric, functional, or inverse functional. Finally, individual-valued properties can be specified as 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 necessary in order to maintain the decidability of the language.
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID> {super=<datavaluedPropertyID>}
{domain=<classID>} {range=<datatypeID>}
[Functional] )
<axiom> ::= ObjectProperty ( <individualvaluedPropertyID> {super=<individualvaluedPropertyID>}
{domain=<classID>} {range=<classID>}
[inverseOf=<individualvaluedPropertyID>] [Symmetric]
[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> )
OWL 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. (Note that the following production is a generalization of the corresponding production in OWL Lite.)
<axiom> ::= Class( <classID> <modality> {<description>} )
<modality> ::= complete | partial
In OWL it is also possible to make a class exactly consist of a certain set of individuals, as follows.
<axiom> ::= EnumeratedClass( <classID> {<individualID>} )
Finally, in OWL 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 OWL class axioms just above.
<axiom> ::= DisjointClasses( <description> {<description>} )
<axiom> ::= EquivalentClasses( <description> {<description>} )
<axiom> ::= SubClassOf( sub=<description> super=<description> )
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>} )
Restrictions in OWL 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 OWL 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=<individual>}
[<cardinality>] )
<cardinality> ::= minCardinality( <positive-integer> )
| maxCardinality( <non-negative-integer> )
| minCardinality( <positive-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 OWL, is either a datatype or a set of data values.
<dataRange> ::= <datatypeID>
<dataRange> ::= OneOf({<typedDataLiteral>} )
OWL property axioms 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> {super=<datavaluedPropertyID>}
{domain=<description>} {range=<dataRange>}
[Functional] )
<axiom> ::= ObjectProperty
( <individualvaluedPropertyID> {super=<individualvaluedPropertyID>}
{domain=<description>} {range=<description>}
[inverseOf=<individualvaluedPropertyID>] [Symmetric]
[Functional | InverseFunctional | Transitive] )
The exchange syntax for OWL is RDF, as specified in the Reference Description. One way of translating an OWL knowledge base in abstract syntax form into this syntax is by giving a transformation of each directive into a collection of n-triples and putting these collections together into a single RDF graph. The n-triples syntax used here is one proposed by the RDF Core WG, which allows QNames to be used in n-triples.
As of yet, no mapping is provided for the imports directive, nor for the unspecified authorship and other properties of an ontology itself. As all OWL Lite constructs are special cases of OWL constructs, transformations are only provided for the OWL versions.
Each type of directive is translated via one of the transformation rules below. In the transformation rules nonterminals are enclosed in angle brackets. Repeating nonterminals are listed using elipses, as in <description1> ... <descriptionn>, this form allows easy specification of the transformation for all values of n, including 0. Optional portions of the abstract syntax (enclosed in square brackets) are optional portions of the transformation (signified by square brackets).
The table below gives the transformation rules that transform the abstract syntax to the OWL exchange syntax. The left column gives a piece of syntax (S) and the right column gives its transformation (T(S)). Some transformations in the table are for directives. Other transformations are for parts of directives. The last transformation is for sequences, which are not part of the abstract syntax per se. This last transformation is used to make some of the other transformations more compact and easier to read.
For many directives these transformation rules call for the transformation of components of the directive using other transformation rules. When the transformation of a component is used in a node position of a triple, the transformation of the construct is part of the production (but only once per production) and the first node of that transformation should be used for that node of the triple.
Bnode identifiers here must be taken as local to each transformation, i.e., different identifiers should be used for each invocation of a transformation rule.
| Abstract Syntax (and sequences) - S | Transformation - T(S) |
| <ID> | <ID> |
| <literal> | <literal> |
| <datatypeID> <literal> | <literal> (NB: This depends on RDF Core datatypes.) |
| imports ( <URI> ) | [To be determined.] |
|
Class( <classID> [partial] [complete] <description1> ... <descriptionn>) |
<classID> rdf:type owl:Class . [<classID> rdfs:subClassOf _:x .] [<classID> owl:sameClassAs _:x .] _:x owl:intersectionOf T(SEQ <description1> ... <descriptionn>) . |
|
EnumeratedClass( <classID> <individualID1> ... <individualIDn> ) |
<classID> rdf:type owl:Class . <classID> owl:sameClassAs _:x . _:x owl:OneOf T(SEQ <individualID1> ... <individualIDn>) . |
| DisjointClasses( <description1> ... <descriptionn> ) | T( <descriptioni> ) owl:DisjointWith T(<descriptionj> ) 1 ≤ i < j ≤ n |
| EquivalentClasses( <description1> ... <descriptionn> ) | T( <descriptioni> ) owl:sameClassAs T( <descriptionj>) 1 ≤ i < j ≤ n |
| SubClassOf( sub=<description1> super=<description2> ) | T( <description1> ) rdfs:subClassOf T(<description2> ) |
|
DatatypeProperty( <name> super=<super1> ... super=<supern> domain=<domain1> ... domain=<domainn> range=<range1> ... range=<rangen>} [Functional] ) |
<name> rdf:type owl:DatatypeProperty . <name> rdfs:subPropertyOf <super1> . ... <name> rdfs:subPropertyOf <supern> . <name> rdfs:domain T(<domain1>) . ... <name> rdfs:domain T(<domainn>) . <name> rdfs:range T(<range1>) . ... <name> rdfs:range T(<rangen>) . [<name> rdf:type owl:UniqueProperty . ] |
|
ObjectProperty( <name> super=<super1> ... super=<supern> domain=<domain1> ... domain=<domainn> range=<range1> ... range=<rangen> [inverseOf=<inverse>] [Symmetric] [Functional | InverseFunctional | Transitive] ) |
<name> rdf:type owl:ObjectProperty . <name> rdfs:subPropertyOf <super1> . ... <name> rdfs:subPropertyOf <supern> . <name> rdfs:domain T(<domain1>) . ... <name> rdfs:domain T(<domainn>) . <name> rdfs:range T(<range1>) . ... <name> rdfs:range T(<rangen>) . [<name> owl:inverseOf <inverse> .] [<name> rdf:type owl:SymmetricProperty . ] [<name> rdf:type owl:FunctionalProperty . ] [<name> rdf:type owl:InverseFunctionalProperty . ] [<name> rdf:type owl:TransitiveProperty . ] |
| EquivalentProperties( <ID1> ... <IDn> ) | T( <IDi> ) owl:samePropertyAs T( <IDj> ) . 1 ≤ i < j ≤ n |
| SubPropertyOf( sub=<ID1> super=<ID2> ) | T( <ID1> ) rdfs:subPropertyOf T(<ID2> ) . |
| unionOf(<description1> ... <descriptionn> ) | _:x owl:unionOf T(SEQ <description1> ... <descriptionn>) |
| intersectionOf(<description1> ... <descriptionn> ) | _:x owl:intersectionOf T(SEQ <description1> ... <descriptionn>) |
| complementOf( <description> ) | _:x owl:complementOf T(<description>) |
| oneOf(<individualID1> ... <individualIDn> ) | _:x owl:oneOf T(SEQ <individualID1> ... <individualIDn>) |
| oneOf(<datatypeID1> <value1> ... <datatypeIDn> <valuen> ) |
_:x owl:oneOf T(SEQ <datatypeID1> <value1> ... <datatypeIDn> <valuen>) |
| restriction(<ID> <component1> ... <componentn> ) | _:x owl:intersectionOf T(SEQ(restriction(<ID> <component1>) ... restriction(<ID> <componentn>))) |
| restriction( <ID> allValuesFrom=<range> ) | _:x rdf:type owl:Restriction . _:x owl:onProperty <ID> . _:x owl:allValuesFrom T(<range>) . |
| restriction( <ID> someValuesFrom=<required> ) | _:x rdf:type owl:Restriction . _:x owl:onProperty <ID> . _:x owl:someValuesFrom T(<required>) . |
| restriction( <ID> value=<value> ) | _:x rdf:type owl:Restriction . _:x owl:onProperty <ID> . _:x owl:hasValue T(<value>) . |
| restriction( <ID> minCardinality=<min> ) | _:x rdf:type owl:Restriction . _:x owl:onProperty <ID> . _:x owl:minCardinality "<min>" . |
| restriction( <ID> maxCardinality=<max> ) | _:x rdf:type owl:Restriction . _:x owl:onProperty <ID> . _:x owl:maxCardinality "<max>" . |
| restriction( <ID> cardinality=<card> ) | _:x rdf:type owl:Restriction . _:x owl:onProperty <ID> . _:x owl:cardinality "<card>" . |
| Individual( [<ID>] type=<classID1> ... type=<classIDn> (<ID1> <value1>) ... (<IDn> <valuen>)) |
[<ID> owl:sameIndividualAs _:x .] _:x rdf:type <classID1> . ... _:x rdf:type <classIDn> . _:x <IDi> T(<value1>) . ... _:x <IDn> T(<valuen>) . |
| SameIndividual( <ID1> ... <IDn> ) | <ID1> owl:sameIndividualAs <IDj> . 1 ≤ i < j ≤ n |
| DifferentIndividuals( <ID1> ... <IDn> ) | <ID1> owl:differentIndividualFrom <IDj> . 1 ≤ i < j ≤ n |
| SEQ <item1> ... <itemn> | _:l1 rdf:type owl:List . _:l1 owl:first T(<item1>) . _:l1 owl:rest _:l2 . ... _:ln rdf:type owl:List . _:ln owl:first T(<itemn>) . _:ln owl:rest owl:nil . |
The above rules transform
Individual(type=ex:Book (dc:author (Individual (ex:name "Fred"))))
to
_:x rdf:type ex::Book . _:x dc:author _:x 1 _:x1 ex:name "Fred" .
and
Class(ex:Student complete ex:Person
restriction(ex:enrolledIn allValuesFrom=ex:School minCardinality(1))
to
ex:Student rdf:type owl:Class . ex:Student owl:sameClassAs _:x . _:x owl:intersectionOf _:l1 . _:l1 rdf:type owl:List . _:l1 owl:first _:lr . _:l1 owl:rest owl:nil . _:lr owl:intersectionOf _:lr1 . _:lr1 rdf:type owl:List . _:lr1 owl:first _:r1 . _:lr1 owl:rest _:lr2 . _:lr2 rdf:type owl:List . _:lr2 owl:first _:r2 . _:lr2 owl:rest owl:nil . _:r1 rdf:type owl:Restriction . _:r1 owl:onProperty ex:enrolledIn . _:r1 owl:allValuesFrom ex:School . _:r2 rdf:type owl:Restriction . _:r2 owl:onProperty ex:enrolledIn . _:r2 owl:minCardinality "1" .
A collection of triples is an OWL knowledge base in triple form if it is the result of the above transformation of an OWL knowledge base in abstract syntax form and, moreover, the abstract syntax form does not mention any of the URI references that are the normal expansion of the following names:
rdf:type, rdf:Property, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain, rdfs:range, owl:Class, owl:sameClassAs, owl:DisjointWith, owl:oneOf, owl:unionOf, owl:intersectionOf, owl:complementOf, owl:samePropertyAs, owl:inverseOf, owl:DatatypeProperty, owl:ObjectProperty, owl:SymmetricProperty, owl:UniqueProperty, owl:UnambiguousProperty, owl:TransitiveProperty, owl:Restriction, owl:onProperty, owl:toClass, owl:hasClass, owl:hasValue, owl:minCardinality, owl:maxCardinality, owl:cardinality, owl:sameIndividualAs, owl:differentIndividualFrom, owl:List, owl:first, owl:rest, owl:nil.
This transformation is not injective, as several OWL abstract knowledge bases that do not use the above reserved vocabulary can map into the same collection of triples. However, the only cases where this can happen is with constructs that have the same meaning, such as several DisjointClasses axioms having the same effect as one larger one. It would be possible to define a canonical inverse transformation.
The Joint US/EU ad hoc Agent Markup Language Committee developed DAML+OIL, which is the direct precursor to OWL. Many of the ideas in DAM+OIL and thus in OWL are also present in the Ontology Inference Layer (OIL) .