Re: Reification as nesting

----- Original Message -----
From: "pat hayes" <phayes@ai.uwf.edu>
To: "Tim Berners-Lee" <timbl@w3.org>; "Drew McDermott"
<drew.mcdermott@yale.edu>
Cc: <www-rdf-logic@w3.org>
Sent: Tuesday, June 05, 2001 11:50 PM
Subject: Re: Reification as nesting
[...]
> 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.).

Agreed.  One should be careful one doesn't suggest that htere are two types
of things, a "triple" and an "assertion". They are the same thing.
If you assert the triples in a nest (ugh) then you don't directly assert the
ones in a subnest.

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

Certainly.

> No, three things. Third, it must be possible to somehow label a nesting.

In what sense?  I found in N3 I did *not* want the identity of a (ugh)
nesting to
be anything other than the set of triples in it.  You can use an external
triple to connect another resource to a nesting.   You could say they
were daml:equivalentTo each other. But they wouldn't be the same thing
in the language.

A nesting {curly bracketted formula in n3} is like a literal string in that
way.
You can't -- and don't need to -- label a literal.

Let's see... below you use a triple as an item in a triple.

[a b [c d e]
which one can assume is shorthand for

      [a b _g]
_g  [c d e]

with anonymous _g.  So you have triples with addresses, or a restricted
form of quad.

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

:)

This is more or less  what happens in N3,  except that a statement itself is
not surfaced as an extra type in the language. The (ugh) nest is.   You can
easily identify a statement by giving a nest with only one statement in it.
It can be a subtype of nest, if you like.  This reduces the number of things
in the language, which makes it simpler.  (Analogy: Using just
strings with no special syntax for a charaacter -- as in eg Python)

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

_g0  kif:forall ?x _g1
_g1 kif:implies ?g2 _g3
_g2  r  ?x  .
_g3  Q  ?x _g4
_g3  etc a  b

( ... tim thinks     {  {?x a R}  kif:implies {?x Q (a b)}  } kif:forall ?x.
)

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

An alternative is to map R to a Class.  This is the natual RDF 1-ary
predicate.
The "." in the object position becomes a "rdf:type" dummy in the predicate
position, if you like.

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

Yes, "etc" is a useful kludge.  Does it work?  i'm not sure, as
I before I could say yes I would want to feel that the predicates and
nestings had well-defines meanings.  For example, what is the object
of Q?  The statement etc(a,b)?  Not really.

In N3 I distinguish between a formula which has a meaning { the:sky ;is
:blue } and the
list of objects (a  b c).

This is not the same as in KIF and LISP, where you can only tell what is a a
function
and what is a datastructure by context.

[[[ BTW  I was looking at mapping lists into triples in
an alternative way and came up with the predicate "list1" which seeds lists,
in that     list1(x, y) means x is a list  containing just y.  Any list used
as a predicate
indicates that its subject is a list containing first the object and then
the elements of that list.

The 3 statements

list1(x,c)
x(z,b)
z(w,a)

would mean that w was a list contain 3 elements (a b c).

That list could be written in N3 as  [[[list1 c] b] a] although one would of
course
use a shorthand.  (Compare  [first a; rest[first b;rest[first c; rest nil]]]
in daml lists)

(Axioms into daml:  list1(x,y) => type(x,list) &first(x,y) & rest(x,nil)
                 type(x,list) & x(y,z) => type(y,list) & first(y,z) &
rest(y,x)

This connects with Dan's way of making predicates from a seed. Eg to write
z=y+3

     isAFunctionWhichIncrementsBy(x,3)
     x(y,z)

This form of list is weirder, but more efficient than the daml:first and
daml:last mapping.
While human-hairy it is RDF-ok.  Each predicate has a meaning.
]]]

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

Well, it wouldn't know what that meant, but would it be false?
If so, you *are* breaking RDF.  N3, with one exception to be fixed, is built
up
out of RDF triples in the sense that if you come across one at the top level
it can be taken as asserted and for example asserted independently of
the other triples.  So an RDF or DAML application would not be mislead.
If the topmost triple is being asserted, why whouldn't RDF do something with
it?

> This also works for containers, by the way eg
> [rdf:bag a [etc b [etc c d]]]

(or you could assert the bagness start at the bottom, in your notation
[etc a[etc b[bag c d]])

But these triples are not statements.  They are objects.
As well of having predicates whic assert something is(sky, blue)
we have predictates with construct something bag(apple, orange).
This is fine if you are brought up on LISP I suppose.  Read "etc" as "pair".

Makes me nervous, though.   I etc it.
[sic]

I could look at the schema or other info about the thing in the
predicate slot to find out whether it gives
an assertion or not.  We are extending the language to have
a new part of speech.

BTW I would point out that to represent a set of assertions is messy.
[kif:and [is sun out] [etc [is sky blue] [is grass green]]].
Another reason for making the set of statements the new concept.

> abbreviated by
> [rdf:bag a b c d]
> which uses fewer triples than the current technique.

yes

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

That is one way.  You might find metadata in a schema (etc)
which would type these pseudo-predicates in some way.

or, linking though the predicates as in the list1 example
works. You can do the same with bag1.

In your notation  [[[bag1 d]

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

another use for 9-bit bytes ;-) **

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

Tim
_____________________________________________________________
** --one shilling the box-- Allow me to sell you a couple?
I once worked with some hardware which had some 9-bit memory because the
designers felt these were so useful, and a waste of 16-bit memory space.

Received on Wednesday, 6 June 2001 18:07:50 UTC