Re: Reification as nesting

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