Re: (Part 1) Where did these syntax constraints come from?

From: Frank van Harmelen (
Date: 01/07/01

Dear Joint Everybody,

This message and the next one is the reply from Ian and me on your
queries and remarks about the DAML+OIL material over the past week.

We've separated our reply out in two messages:
- the next message, which deals with all of the smaller remarks.
- this message, which deals with the hard issues:
  [1] Where did these syntax constraints come from?
      (answer: they should not be there)
  [2] mixing DAML+OIL with arbitrary RDF?
      (answer: that is allowed but we don't say what it means)

Summary: we propose to resolve these two points through additional
introductory text in the reference document. A proposal can be
temporarily found at
(see dark shading for the changed part)

Some/much/all of this should be food for the teleconf this Tuesday,
but feel free to react before then!


[1] Where did these syntax constraints come from?

It was rightly pointed out by Dan and Tim that the reference document
seems to suggest that DAML+OIL demands a particular syntactic form of RDF.
For example, it seems to demand that a class definition looks like:
   <rdfs:Class ID="Cups"/>
and seems to disallow:
   <rdf:Description ID="Cups">
     <rdf:Type resource=""/>
which yields the same underlying RDF graph, and is therefore equivalent
to the first as far as an RDF application is concerned.

This is not what we had wanted to suggest. We believe the situation to
be as follows:
- DAML+OIL assigns a specific semantics to certain RDF graphs
  (in this respect, it is exactly similar to RDF Schema)
- It's the underlying RDF datagraph that counts, not the particular
  surface RDF syntactic form that is used to describe it
- RDF allows for multiple syntactic forms for the same underlying datagraph
- since DAML+OIL assigns semantics to certain RDF graphs, DAML+OIL
  should also be insensitive to the particular syntactic form used

So, ideally, the reference document should be specified in terms of
RDF triples, not in terms of a specific RDF syntactic form (notice
that the model-theoretic semantics is organised in the proper way: in terms
of triples, not syntax). 

However, this would
(a) require a total rewrite of the reference document (which is not
very attractive given our desire to release soon), and
(b) we doubt if this would result in a reference document that would
help a large class of readers to use DAML+OIL (it would end up looking
just like the model-theoretic semantics). 

So our proposal is to add an introductory paragraph to the reference
document, stating that different syntactic forms are allowed, as long
as they yield the same RDF triples as the ones that result from the
syntax used in the reference document. We've added such a paragraph to
the introduction of the reference document. The proposal can be found at

[2] mixing DAML+OIL with arbitrary RDF?
Dan suggested that mixing "arbitrary" RDF with DAML+OIL should be
allowed. Of course, there is no way of stopping anybody from doing
this. But the important point is that DAML+OIL has nothing to say on
the consequences (or lack thereof) for the semantic interpretation of
DAM+OIL statements. DAML+OIL can only provide a semantic
interpretation for those parts of an RDF graph that instantiate the
schema defined in daml+oil.daml. For example, if you take the
perfectly innocent class definition for Person from the
daml+oil-ex.daml, and then add 

<rdf:Description about="#Person">
    <Creator>Ora Lassila</Creator>

then the semantics don't say what this means or what it would
imply for instances of Person. (Beyond of course the minimal
Subject-Verb-Object semantics of RDF).

Taking one of the examples from Dan's email:

        <rdfs:TransitiveProperty ID="ex3">
                <!-- even RDF/DAML properties can have arbitrary claims
                made about them; claims using terms we don't define, no?

Yes, this is allowed, but no, we have nothing to say on what this
means. We propose to make this point clear in the introduction to the
reference document. See
for the proposed text.

This archive was generated by hypermail 2.1.4 : 04/02/02 EST