- From: pat hayes <phayes@ai.uwf.edu>
- Date: Tue, 5 Jun 2001 22:50:17 -0500
- To: "Tim Berners-Lee" <timbl@w3.org>, "Drew McDermott" <drew.mcdermott@yale.edu>
- Cc: www-rdf-logic@w3.org
>----- Original Message ----- >From: "Drew McDermott" <drew.mcdermott@yale.edu> >To: <www-rdf-logic@w3.org> >Sent: Tuesday, June 05, 2001 12:51 PM >Subject: Reification as nesting > > > > > > [Wolfram Conen] > > I haven't found too much in the spec that forbids to interpret that >what > > is being called "reification" in RDF M&S as nesting (and only as > > nesting). > > > > Yes, I think you're right. A lot of the arguments about this issue > > are based on the misconception that the advocates of "reification" > > were talking about quotation. The rdf:quote mechanism clearly shows > > that one doesn't actually have to reify to achieve the desired > > effect, which is to block the inexorable triple-inference rule. > >It seems to me that whether one "has" to depends on how one is trying to >"build on top" of RDF. >If "building on top" means producing a language which will include RDF as a >subset, >then one does not need reification to do nesting. If "building on top" >means finding a way to convey the semantics of something in the new >langauge using only pure RDF and a bunch of new special Properties, >then one needs reification. Even reification will not do that, in general. (If something is ever built that can do that, then it will probably use reification, but reification won't do the job by itself.) But I think that is all an aside: we don't need to get to that very advanced stage yet. Just being able to distinguish subexpressions would be an enormous step forward. > I feel that in the long run, the former is the >practical route, I agree. >but it is nice to have the latter relationship as well. >The two ideas can coexist in the world. > > > The good news is that a consensus is emerging, based on the idea of > > drawing a line around an RDF substructure with a note saying "Don't > > automatically infer the stuff in here." > >Good! > > > The bad news is that there are too many terms being used for this > > idea, including "context," "nesting," and "reification." > >I don't see a conflict between "nesting" (what is going on) >and "context" (a relationship between one level of nesting >and the next highest). > >Under DanC's influence I have been moving away from [Conceptual Graphs'] >"context" >as a noun for the thing to "formula". So one formula can be the context >for another (sub-)formula. I know I get overly fussy about nomenclature, but "context" is a very over-used word, with so many meanings that it is almost guaranteed to be misunderstood. Maybe it would be best to invent a completely artifical new word. That is why I rather liked "nesting", which is fairly free of mathematical/logical/linguistic baggage. > > > These terms > > have lots of distracting associations with other topics. Some fairly > > neutral party (Lynn Stein?) should pick a term, and then we can all > > agree to use it, and turn our attention to the details of how to > > indicate nesting, or whatever we call it. > > > > -- Drew McDermott But PLEASE let us not call it "reification". I will call it "nesting" until someone renames it. There are two substantive things that nesting needs to be able to do. First, it must provide a way to distinguish triples from assertions. Some triples may be asserted, but the triples in a nesting aren't (at least, not directly; something else might be able to infer them, or something.). Second, nesting needs to be recursive, so that one can describe subexpressions. That is, a nest might have other nests inside it. No, three things. Third, it must be possible to somehow label a nesting. Seems to me that all this can be done in one fairly simple way, by allowing the subject and object of RDF triples to themselves be RDF triples (not reifications of triples, but actual triples.) These 'inner' triples are not asserted, and the 'verb' of the triple that points to them provides the needed labelling. The distinction between subject and object provides the distinction between subnesting and nesting, much in the way that LISP uses CDRs to indicate list members and encodes sublists in the CAR. This would be a single, simple change to RDF which would support the kind of processing that CWM and Jos Deroos's Euler system are doing, and indeed would provide enough flexibility to encode abitrary list structures, so could easily accomodate, say, KIF syntax; it would leave all current RDF unchanged; it would allow a single triple to be asserted as a relational fact, without interfering with the use of triples to encode more advanced syntax; and it allows everything to ultimately consist of triples, preserving the universal triplitude that appeals to many people. Writing triples as [V s o], (I know this isnt the usual way round) the following piece of KIF (forall (?x)(implies (R ?x)(Q ?x a b))) might look like this: [Kif:forall ?x [Kif:implies [R ?x .] [Q ?x [etc a b]] where I have inserted a dummy dot to fill out the unwanted object of the inner triple; these could be omitted by convention, of course. 'etc' means a continuation of whatever structure it occurs in, in this case a relational sentence with more than two arguments. Again, it would be natural to allow things like [... a b c d] as an abbreviation for [....a [etc b [etc c d]]]. Ive inserted the "Kif:" in the spirit that it would be up to something 'on top' of RDF to actually interpret these nestlings; RDF's job is just to not think that they belong to it and are actually being asserted. The topmost triple of the nesting *is* being asserted, but since its verb starts with "Kif:", RDF is warned not to try to do anything with it, and so it would not attempt to interpret it as a relation called "forall" applied to two arguments. This also works for containers, by the way eg [rdf:bag a [etc b [etc c d]]] abbreviated by [rdf:bag a b c d] which uses fewer triples than the current technique. The only snag I can see with this idea is that it would require some work to reconstitute which triples in an arbitrary set of triples were being asserted and which were not. That is, if some of this 'nested' RDF is simply rendered down into a set of isolated triples, then the question of whether one of these rendered-down pieces is a top-level (asserted) triple or not will depend on what other triples, if any, are pointing to it. If this kind of sensitivity of triple-assertions to their context is seen as a problem, there are several ways to overcome it, but all the ones I can think of seem to require either some extension of the triples model to something slightly larger (eg a triple with a marker bit), or some global extension of the entire triple-based model to something more complex (eg some global notion of context), or some kind of datastructure hacking, or else some global labelling convention whereby unasserted triples can be recognised. However, I would urge that this degree of contextual sensitivity should just be accepted as part of the burden of information trafficking, much as checksums are needed to make sure that all the packets have arrived. It seems a small price to pay for a great gain in expressiveness and flexibility. Pat Hayes --------------------------------------------------------------------- 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
Received on Tuesday, 5 June 2001 23:50:21 UTC