Coordination points between RDF(S) and DAML+OIL.
Frank van Harmelen
10 July 2001
after discussion in the
This document describes which areas of RDF and RDF Schema need
attention based on our experiences with defining DAML+OIL as an
extension of RDF Schema. It is input from the DAML+OIL Joint Committee
to the RDF Core working group.
What does DAML+OIL depend on from RDF(S)
DAML+OIL builds on the basic triple-structure provided by RDF.
In its essence all that DAML+OIL does is to assign a specific
interpretation to certain designated RDF triples (see the
remarks in the DAML+OIL reference document and
in the model
theoretic semantics of DAML+OIL.
Some of these designated triples are inherited from RDF Schema.
DAML+OIL assigns a semantics for these triples which we believe
was also the intended semantics of these triples in the RDF Schema
We use RDF Schema classes, the class hierarchy organisation, and the
structuring of properties: rdf:type, rdfs:class, rdf:value,
rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain and rdfs:range.
What does DAML+OIL not use at all
We have chosen to not assign semantics to the following elements of
RDF and RDF Schema:
Reification of statements:
The reason for this is twofold. Firstly, no
such language construct was felt necessary for a basic ontology
infrastructure language, and secondly the semantics of the RDF
Schema construction is poorly understood.
Although a notion of containers is required in DAML+OIL
(in particular sets), the containers as provided by RDF have the
wrong properties to be useful for us. An important property of
containers in RDF (whether by accident or by design) is that they
cannot be "closed". External sources can always make additional
statements the contents of a container, effectively "adding"
elements. In DAML+OIL, it is crucial to be able to state that a
container contains exactly the indicated arguments, and >*no more*<.
This is important in for instance the "disjointUnionOf statement".
Such a "closure condition" on containers is impossible (or at least
very hard) to express using RDF containers.
RDFS - meta-class organization:
With meta-classes in this context we mean classes that have other
classes as their members. RDF Schema allows such meta-classes
the explanation on rdf:type in the RDF Schema recommendation).
DAML+OIL allows only instances to be members of
classes. Classes can be a subclasses of other classes, but never
members. I.e. DAML+OIL does not contain meta-classes. To be sure, as
part of a DAML+OIL document, one can write a statement making one
class an instance of another class, but such a statement is not
assigned any DAML+OIL semantics.
Although meta-classes are therefore not available to users of
DAML+OIL (in the sense described above, namely that DAML+OIL
provides no semantics for it), meta-classes in RDF Schema have been
used by the designers of DAML+OIL to define DAML+OIL in terms of
RDF Schema. For example, the RDF Schema definition
of DAML+OIL starts with the definition of two meta-classes, namely
the class of object-classes and the class of all datatype classes.
- meta-classes are classes with other classes as members
- RDF Schema allows such meta-classes
- such meta-classes are not given any semantics under DAML+OIL
- the RDF Schema definition of DAML+OIL does exploit such
What changes does DAML+OIL require
As indicated in the DAML+OIL reference document
summarised in a message to the www-rdf-logic mailing list,
DAML+OIL takes exception to the intended/inferred semantics of RDF
Schema in three places:
What areas are problematic
- Human unreadable syntax:
RDF(S) XML syntax is well suited for machine processing, but very
unwieldy for human use. There is a real need for such a human readable
syntax: ontologies are being scribbled on white-boards, sent around in
email-messages, used in presentations, etc. This holds for RDF(S)
information as much as it does for DAML+OIL information.
- Normalised constructions:
There is currently no way to preserve different syntactic forms for
the same RDF graph in many RDF implementations. Although strictly speaking two
syntactic forms of the same RDF graph are equivalent, the syntactic
forms nevertheless still often carry different connotations for human
readers and writers.
These subtle differences between different syntactic forms are lost
because it is not possible in RDF to distinguish between different
syntactic forms (since they correspond to the same graph-model, and are
The March 2001 release of DAML+OIL included datatypes in the language,
using the basic datatypes from XML Schema as its foundation. It would be
more appropriate if RDF Schema already provided such datatypes
(possibly in a similar way as is now done in DAML+OIL).
Some of the DAML+OIL syntax has become unwieldy because RDF does not
provide a "scoping" or "bracketing" mechanism. The syntax for property
restrictions in DAML+OIL is an example of this.
In general, we feel that the layering between RDF and RDF Schema is
not very natural: both language provide very natural constructions
(data-triples, class-hierarchy), but also contain rather sophisticated
constructions (e.g. reification) that we would not expect in such
- Syntax of URIs:
Although there is a syntax for a general URIs, there does not appear to
be a good specification for the URIs that appear in RDF documents, in
particular, how URIs are composed in the presence of
namespaces and RDF ``fragments'', including whether namespaces are
permissable in URIs that are not XML URIs. There has been considerable RDF
debate on these points.
- Semantics of URIs:
It seems reasonable to interpret URI's as logical constants. This
raises the question what the total universe of discourse is for
interpreting DAML+OIL. (This is important as the semantics of a DAML+OIL
knowledge base is relative to a given universe of discourse).
Does the set of URI's have a non-trivial structure?
- Can two syntactically-different URIs point to the same domain element?
- can the same URI string name a different resource at different times?
- Can a URI (sometimes) fail to denote
- What is the relation (if any) between the semantic denotation of
a URI as a logical constant and that URI accessing a web-page (if any)?
$Revision: 1.2 $ of $Date: 2001/07/10 23:58:48 $