From: Pat Hayes (phayes@ai.uwf.edu)
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 phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST