W3C home > Mailing lists > Public > www-rdf-logic@w3.org > June 2001

Re: Reification as nesting

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Wed, 6 Jun 2001 10:36:03 -0400 (EDT)
Message-Id: <200106061436.f56Ea2Q04187@pantheon-po01.its.yale.edu>
To: www-rdf-logic@w3.org

   [Pat Hayes]
   ....I rather liked "nesting", which is 
   fairly free of mathematical/logical/linguistic baggage.

My vote would be for "nesting" also.

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

I've thought about this, following Jonathan Borden's proposals, and
decided that it's a nonissue.  An expression, or set of triples, is
asserted if someone asserts it (e.g., includes it at the top level of
their web page).  In ordinary logical notation, you don't need to have
a special system of marks to distinguish the "or" expression from the
"and" expression in (or p (and q r)); the outer expression may or may
not be asserted, depending on the context, but its being asserted
doesn't imply that the inner and-expression is asserted.

   [quote pulled back from a later part of Pat's message on the same 
    topic:]
   ... this idea ... 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. 

Again, I don't see it as a problem.  First, if you render a nesting as
a flat set of triples, you do not discard the nesting boundary, 
however represented.  In fact, the way I read the RDF spec is that you
*have* to render any expression as a flat set of triples.  The change
we are discussing is to amend this to "sets of triples with nesting
boundaries."

Second, the existence of a pointer from some unknown place to a given
nesting doesn't change anything, at least, not in a way we have to
worry about.  When manipulating a nesting, an agent will always know
the path by which it reached the nesting, and so will know how to
interpret the nesting in the context defined by that path.  E.g., if
Tony Blair's web page has a pointer to the Labor Party's platform (or
whatever they call a statement of principles in Britain), saying "This
nesting is true," and you get to the platform from Blair's web page,
then presumably what you care about is what it is Blair endorses.  The
fact that there might be a pointer from the Conservative Party saying
"Every (most? at least one?) item in this nesting is false" is of no
particular relevance.  (Of course, there will always be agents who
have wandered into a nesting from a useless direction, given their
goals; but finding useful places on the web to wander from is not the
issue here.)

   Second, nesting needs to be recursive, so that one can 
   describe subexpressions. That is, a nest might have other nests 
   inside it.

Yes.

   Third, it must be possible to somehow label a nesting.

I'm not sure I understand what "label" means here.

   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. 

...and the needed contextual information.

   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. 

Do you really want to differentiate subject and object?  I thought you
were going to say that it's the distinction between an atom (a
resource) and a subtriple that indicated nesting.

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

I think we still have some work to do here.  By casually changing the
order of subject-verb-object, you've obscured the fact that this
expression really looks like this:

   <?x, Kif:forall, <<?x, R, .>, Kif:implies, <?x, Q, <a, etc, b>>>>

But a vanilla RDF processor might ask what ?x refers to.  You try to
ward off this possibility:

   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.

but as RDF stands now it would have to assume at least that there were
two entities being talked about, ?x and <<?x ...> ...>.  It's not at
all clear what entity ?x might refer to.

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

I have a slight preference for having it abbreviate 
[... a [etc b [etc c [etc d nil]]]]
but it doesn't make much difference.  It would if d could itself be an
etc, but that's not possible, if I understand etc correctly.

                                             -- Drew McDermott
Received on Wednesday, 6 June 2001 10:36:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:40 GMT