The OWL Abstract Syntax and Semantics (S&AS) 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 S&AS, 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.
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.
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 must be
a triple:
i rdf:type c
where c is an owl:Class or
owl:Restriction.
URI references for classes, properties (both object and datatype) 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 with predicate rdf:type.3
If a node x has rdf:type
owl:Restriction then the following should be the case:
rdf:type3.owl:onProperty, with the object of that triple being an
owl:ObjectProperty or
owl:DatatypeProperty.owl:someValuesFrom. In this
case, the type of the property which is the object of the
owl:onProperty triple should be appropriate. By this we
mean that if the object of this triple is a datatype, the property
should be an
owl:DatatypeProperty. If the object is a class
expression, the property should be an
owl:ObjectProperty. This typing information should be
present (due to the restrictions outlined above).owl:allValuesFrom. Similar
restrictions hold as for owl:someValuesFromowl:hasValue. If the type of the
property involved in the owl:onProperty triple is
owl:ObjectProperty then the object of this triple should
be an individual. If the type of the
property involved in the owl:onProperty triple is
owl:DatatypeProperty the the object of this triple
should be a data literal. owl:minCardinality. The object
of this triple should be a data literal representing a non negative
integer.owl:maxCardinality. Restriction
as for owl:minCardinality. owl:cardinality. Restriction as
for owl:minCardinality. x is the subject should
have predicate owl:equivalentClass or
owl:disjointWith.
For any triples with predicate 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 must contain one of:
x rdf:type owl:Class
or
x rdf:type owl:Restriction.
and one of
y rdf:type owl:Class
or
y rdf:type owl:Restriction.
For any triples with predicate 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 must contain either:
p rdf:type owl:ObjectProperty q rdf:type owl:ObjectProperty.
or
p rdf:type owl:DatatypeProperty q rdf:type owl:DatatypeProperty.
Triples with predicate rdfs:domain should have as their
subject an owl:ObjectProperty or
owl:DatatypeProperty and as their object an
owl:Class or owl:Restriction.
Triples with predicate 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 with type owl:DataRange.
Both the subject and object of an owl:inverseOf triple
must have type owl:ObjectProperty.
For any triples with predicate
owl:sameIndividualAs4 or
owl:differentFrom, the subject and object must 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:
owl:distinctMembers, the object of which should be a
(well-formed) rdf:List, all of whose elements are
individuals.Boolean Operators (and, or, not) are represented in OWL using
owl:intersectionOf, owl:unionOf and
owl:complementOf.
The subject of an owl:complementOf triple must be an
owl:Class, the object must be either an
owl:Class or owl:Restriction.
The subject of an owl:unionOfor
owl:intersectionOf triple must be an
owl:Class, the object must 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>
If the owl:Class is a bnode (i.e. the class is
unnamed), then it can only be the subject of at most one triple with
predicate
owl:intersectionOf,
owl:unionOf or owl:complementOf. If the
class is named, any number of such triples are allowed.
The subject of any triple with predicate owl:oneOf must be
either an owl:Class or an owl:DataRange. In
the case of the former, the object must be a (well-formed)
rdf:List, all of whose elements are individuals. In the case of the latter, the object must 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.
In general, the S&AS 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 description 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.
In general, bnodes occurring in the graph either represent unnamed individuals, or should be exactly one of the following:
rdfs:subClassOf,
owl:equivalentClass, owl:disjointWith,
owl:someValuesFrom, owl:allValuesFrom or
rdf:type triple.rdf:type triple with object
owl:AllDifferent.rdf:List.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).
Ontologies may contain assertions of ground facts (e.g. triples
that assert the properties of individuals). The properties used in
these assertions must be an
owl:ObjectProperty or
owl:DatatypeProperty. The subject of any such triple must
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).
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
[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
In addition, for restrictions, we can have:
x rdf:type owl:Restriction x rdf:type rdfs:Class x rdf:type owl:Class
[4] Or owl:sameAs.