From: Pat Hayes ([email protected])
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.
><snip>
>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?
Pat
--
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola, FL 32501 (850)202 4440 fax
[email protected]
http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST