Re: Can one layer a DAML+OIL model theory on top of RDF?

From: Pat Hayes (
Date: 11/29/01

>[This is a revision of an earlier message that I sent out last week.]
>I don't think that it is possible to create a DAML+OIL model theory that is
>both 1/ based on the RDF graph abstract syntax and 2/ compatible with the
>new RDF model theory.

OK, I see your point. But this problem has nothing particularly to do 
with the MT itself, right? It would probably be true with *any* MT 
for RDF, since it arises from DAML's use of rdf:parseType to encode 
DAML syntax. There is no way that any semantics for RDF can 
accomodate in a principled way any ad-hoc use of RDF structures to 
encode meanings, any more than a semantics for LISP can encode the 
meanings of everything implemented in LISP.

>  I say this because the triples generated by
>DAML+OIL logical constructs add extra stuff to models and this extra stuff
>gets in the way of entailment.  (This is similar to the case argued a while
ago concerning arbitrary booleans in RDF.)

We can patch this by invoking the distinction between asserted and 
nonasserted triples.

However, I think that if this is seen as a problem, then the real 
cure is to be found by modifying DAML+OIL rather than by modifying 
RDF. As the DAML reference says, 'DAML+OIL exploits the rdf:parseType 
attribute to *extend the syntax for RDF* '(my emphasis).  No model 
theory can be expected to track extensions to the syntax. In this 
sense, DAML+OIL is not an extension to RDF: it is a different 
language implemented in RDF. It would be better to just stop trying 
to implement it in RDF, and let it be its own language which is a 
genuine *extension* of RDF.

>How can this be fixed?  About the only way I can see is to not produce
>model-theory stuff for the DAML+OIL logical stuff.  However, this is very
>hard if one starts with RDF triples, as how does one tell which triples are
>logical and which are not?

That is exactly why we need to extend RDF rather than try to 
implement everything in it. But in the meantime, one way to patch the 
problem would be to say that the 'logical' triples are not asserted 
triples in the RDF (but that they are being used to assert some DAML 
content, itself specified by further semantic constraints.) That is 
exactly the kind of use I had in mind when putting the 'asserted 
triples' clause into the RDF MT. If we insist on everything being 
encoded into RDF triples, we MUST invoke some way of using triples to 
encode syntax rather than to assert simple properties; this 
distinction does not provide any such way, but it does assume that it 
is provided somehow.

>The situation is *much* better if one starts with XML.   Here it is much
>easier to determine which constructs are logical constructs, and thus do
>not need to be translated into relationships, and which are non-logical
>constructs, and thus do need to be translated into relationships.  Also,
>the non-logcial constructs that are syntactially inside of logical
>constructs can also be treated as they should.

It is certainly easier to encode syntax when one has some syntactic 
structure to do it with, to be sure.

>For example, the last two examples would result in no (new) RDF classes.
>Their semantics would only be employed by enclosing class definitions,
>resulting in the appropriate extension for the class, and not in extraneous
>relationships in the RDF model theory.

See above comments on nonasserted triples.

>As I see it there are really (only) two possibilities:
>1/ Keep the RDF graph (i.e., triple) abstract syntax and use a
>    separate semantic treatment, because of the issues above.  This is the
>    route currently taken by DAML+OIL.   However, it is *not* compatible
>    with the RDF model theory.
>2/ Keep the essence of the RDF model theory, but go directly from a
>    different (tree-based) abstract syntax (such as an XML data model) to
>    the model theory. 
>In my view, the second approach is better.

Yes, I tend to agree. Note however that this could be done, I think, 
in a way that preserves XML-RDF meanings, ie the same MT would work 
for RDF and DAML from within XML.

Alternatively, perhaps we could modify DAML to be a more rational 
extension of RDF, rather than using the barbaric daml:collection 
trick, which I think everyone felt was only a stop-gap, right?


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax

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