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

From: Peter F. Patel-Schneider (pfps@research.bell-labs.com)
Date: 11/30/01


From: Pat Hayes <phayes@ai.uwf.edu>
Subject: Re: Can one layer a DAML+OIL model theory on top of RDF?
Date: Thu, 29 Nov 2001 18:28:18 -0600

[...]
> >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.

Yes, but parseType is not involved.  Think of parseType as a macro, so the
real surface syntax is a list.  However, this list is just triples, and
these triples are given interpretation in the RDF model theory.

> >  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.

Possibly.  However, I am opposed to any use whatsoever of this mechanism. 

> 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.

Yes, but, again, parseType does not play here.  

My view is that DAML+OIL is a different language from RDF.  As such it
should have its own syntax.  However, I also think that DAML+OIL should
include RDF as a sublanguage.

[...]

> >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?

I also think that this would be done.  That is a model theory for DAML+OIL
can be developed that is an extension of the RDF model theory.  Moreover,
the XML syntax for DAML+OIL can include RDF/XML both as a sublanguage (i.e.,
RDF/XML syntax is valid in this language) and as a sublogic (i.e., the
DAML+OIL model theory on this sublanguage is the same as the RDF model
theory). 

(I'm not sure which of the two paragraphs above this satisifes.)

> Pat


peter


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