Rules of Thumb for OWL DL Ontologies

The OWL Abstract Syntax and Semantics (AS&S) document provides a characterisation of OWL ontologies in terms of an abstract syntax, along with a mapping to RDF triples.

The following rules give an informal characterisation of the conditions for an RDF graph to be a DL ontology. This is not intended to replace the characterisation given in AS&S, but instead gives some general pointers — the idea is that if you stick to these guidelines, you're more likely to produce OWL DL ontologies. Nor is this intended to tell you how to turn the triple representation into something closer to the abstract syntax.

Don't mess with the vocabulary

The built-in properties and classes should not be redefined. In general this means that things in the OWL, RDF or RDFS namespaces should not appear as subjects of triples.

Provide Explicit Typing

Everything should have a type1. If any URI reference x is used where a class is expected, the graph should contain a triple stating that 

x rdf:type owl:Class

Similarly, if a property p is used where an object property is expected then there should be a triple2 

p rdf:type owl:ObjectProperty

If a property q is used where a data property is expected then there should be a triple

q rdf:type owl:DatatypeProperty

Any individuals that occur in the ontology should have at least one type specified, i.e. for an individual i, there should be a triple:

i rdf:type c

where c is an owl:Class or owl:Restriction.

Annotation properties should be explicitly asserted as such. Note that this includes "standard" annotation properties such as title and author from the Dublin Core vocabulary. Thus if dc:title is used to make annotation on objects in the ontology, the following triple should be included:

dc:title rdf:type owl:AnnotationProperty

Keep Names Separate

URI references for classes, properties (object, datatype and annotation) and individuals should be disjoint. Thus we cannot have things like: 

x rdf:type owl:Class
x rdf:type owl:ObjectProperty

In particular, this means that we cannot use classes as instances, i.e. 

x rdf:type owl:Class
y rdf:type owl:Class
x rdf:type y

is not valid OWL DL. A general rule here is that if there is a node x in the graph with a triple: 

x rdf:type owl:Class

then x should not appear as the subject of any other triple involving rdf:type.3

Restrictions

If a node x has rdf:type owl:Restriction then the following should be the case:

Class Axioms

For any triples involving rdfs:subClassOf or owl:equivalentClass or owl:disjointWith, both the subject and object of the triples should be an owl:Class or owl:Restriction, i.e. if we have:

x rdfs:subClassOf y

then the graph should contain one of:

x rdf:type owl:Class | x rdf:type owl:Restriction.

and one of

y rdf:type owl:Class | y rdf:type owl:Restriction.

Property Axioms

For any triples involving rdfs:subPropertyOf or owl:equivalentProperty, both the subject and object of the triples should have the same type which should be one of owl:ObjectProperty or owl:DatatypeProperty, i.e. if we have:

p owl:equivalentProperty q

then the graph should contain either: 

p rdf:type owl:ObjectProperty
q rdf:type owl:ObjectProperty.

or 

p rdf:type owl:DatatypeProperty
q rdf:type owl:DatatypeProperty.

Triples involving rdfs:domain should have as their subject an owl:ObjectProperty and as their object an owl:Class or owl:Restriction.

Triples involving rdfs:range should have as their subject either an owl:ObjectProperty or an owl:DatatypeProperty. In the case of the former, the object of the triple should then be an owl:Class or owl:Restriction, in the case of the latter, the object should be either an XML Schema datatype or an owl:oneOf specifying a data range.

Both the subject and object of an owl:inverseOf triple should have type owl:ObjectProperty.

Individual Axioms

For any triples involving owl:sameIndividualAs4 or owl:differentFrom, the subject and object should be individuals.

Note that relating two classes via owl:sameIndividualAs is a very different thing to relating them via owl:equivalentClasses. The former says that the two objects are in fact the same, is actually an example of class as instance, and thus pushes the ontology out of OWL DL. The latter is an assertion that the extension (e.g. the collection of members) of the classes is equivalent.

Similarly, relating classes via owl:differentFrom is not the same as relating them via owl:disjointWith (and is again an example of an OWL Full construct). Two classes may be different objects but still share the same extension.

If a node x has rdf:type owl:AllDifferent, then the following should be the case:

Boolean Class Expressions

Boolean Operators (and, or, not) are represented in OWL using owl:intersectionOf, owl:unionOf and owl:complementOf.

The subject of an owl:complementOf triple should be an owl:Class, the object should be either an owl:Class or owl:Restriction.

The subject of an owl:unionOfor owl:intersectionOf triple should be an owl:Class, the object should be a (well-formed) rdf:List, all of whose elements are either owl:Class or owl:Restriction. These could either be represented explicitly using expanded rdf:Lists, or if RDF-XML is being used, an rdf:parseType="Collection" attribute.

<owl:Class>
 <owl:intersectionOf rdf:parseType="Collection">
  <owl:Class rdf:about="x"/>
  <owl:Class rdf:about="y"/>
 </owl:intersectionOf>
</owl:Class>

Enumerations

The subject of any triple involving owl:oneOf should be either an owl:Class or an owl:DataRange. In the case of the former, the object should be a (well-formed) rdf:List, all of whose elements are individuals. In the case of the latter, the object should be an (well-formed) rdf:List, all of whose elements are data literals. Again, as with the boolean operators, rdf:parseType="Collection" can be used.

Avoid Structure Sharing

In general, the AS&S description of OWL does not permit structure sharing in the RDF representation. This effectively means that an anonymous node in the RDF graph representing a particular descriptions should only occur once (as the object of a triple). Thus things like:

x1 rdf:type owl:Class
x1 rdfs:subClassOf _:y
x2 rdf:type owl:Class
x2 rdfs:subClassOf _:y
_:y rdf:type owl:Class
_:y owl:ComplementOf z

should be avoided. There are some tricky corner cases where this is permitted. In general, however, graphs should use distinct bnodes whenever a class description is used in more than one place.

Avoid Orphan bnodes

In general, bnodes occurring in the graph should be exactly one of the following:

Orphan bnodes, i.e. those which are not the object of a triple are, in general, not allowed (other than the owl:AllDifferent case described above).

Ground Facts

Ontologies may contain assertions of ground facts (e.g. triples that assert the properties of individuals). The properties used in these assertions should be an owl:ObjectProperty or owl:DatatypeProperty. The subject of any such triple should be an individual (which should be typed). The object can either be a reference to an individual (if the property is an owl:ObjectProperty) or a data literal (if the property is an owl:DatatypeProperty).

Miscellaneous

Be careful of the use of owl:Thing. For example, the following OWL-RDF fragment:

<owl:Class rdf:about="#A">
  <rdfs:subClassOf>
    <owl:Thing>
  </rdfs:subClassOf>
</owl:Class>

Does not describe a class A that is a subclass of owl:Thing, but in fact describes a class A that is a subclass of some anonymous instance of owl:Thing. This is thus a use of class as instance and is outside OWL DL. The desired effect of a subclass of owl:Thing is obtained through:

<owl:Class rdf:about="#A">
  <rdfs:subClassOf>
    <owl:Class rdf:about="http://www.w3.org/2002/07/owl#Thing"/>
  </rdfs:subClassOf>
</owl:Class>

Be careful not to confuse owl:Class and rdfs:Class. The following is not in DL due to the fact that c is not given an appropriate type.

x rdf:type rdfs:Class

Similarly, recall that all properties must have a specific type given. The following is not in DL due to the fact that p is only given the general rdf:Property type.

p rdf:type rdf:Property

Notes

[1] Of course the necessity to type everything does not apply to things from the OWL, RDF or RDFS namespaces.

[2] Strictly speaking, if the property is defined as being an owl:TransitiveProperty, owl:SymmetricProperty or owl:InverseFunctionalProperty then this is not necessary.

[3] An exception here is that we can have: 

x rdf:type rdfs:Class
x rdf:type owl:Class

p rdf:type rdf:Property
p rdf:type owl:ObjectProperty

or

q rdf:type rdf:Property
q rdf:type owl:DatatypeProperty

[4] Or owl:sameAs.

Sean Bechhofer, University of Manchester, 03/01/04