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

From: Pat Hayes (
Date: 12/04/01

>From: Pat Hayes <>
>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.

Well, Im not; and I don't think that there is any way to make RDF 
useable without it, or something equivalent, which is why I put it in 
there. What have you got against it so strongly? It is about the 
simplest extension to RDF imaginable that gives it a chance of being 

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

OK, point taken. I was only meaning to refer to the idea of extending 
the syntax.

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

OK, fine. Let take that attitude, with which I agree. But now suppose 
we go on to do something further, which is admittedly rather odd, 
which is to implement that syntax extension in RDF, ie to describe it 
in terms of constructions made up of RDF triples. There is no 
principled objection to doing this, seems to me, *provided that* we 
have some way to distinguish the triples being used to assert content 
(in the RDF sublanguage of the extended language) from those being 
used to encode the new syntax (of the extended language), and to 
interpret each kind of triple appropriately. This is not, to repeat, 
the usual way these things are done; but it does not seem to me to be 
in principle impossible or necessarily undesirable , as long as the 
underlying system is able to bear the burden of making the 
appropriate distinctions. LISP hackers do this kind of thing all the 

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

That seems like the best way to make progress, I have to admit.


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