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.

I'm suggesting that they are not the same: that is the point. Not all 
triples are asserted (or even assertable.) Some assertions are 
totally comprised by a single simple SVO triple which doesnt contain 
any others,  but other assertions assert things that require a larger 
structure, made up of a number of triples, to represent them. Those 
triples that make up that larger thing are not assertions.

>If you assert the triples in a nest (ugh) then you don't directly assert the
>ones in a subnest.

(OK, this 'nesting' terminology is getting out of hand, I agree. But 
I'll stick to it for now.) In the scheme I have in mind, you indeed 
always assert a single triple. However, some of those asserted 
triples may contain other triples. That is called a nest. The triples 
IN the nest, ie those contained inside the top-level, asserted, 
triple, are not asserted, directly or indirectly. (They may be 
inferrable by rules, but then the inferred conclusions produced by 
the rules would be at the top level, not inside a nest, eg if one 
inferred q from p and [implies p q] , then - after doing the 
inferring - it would be at the top level.

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

I agree. The labelling can be done using the outermost triple, which 
is how you do it in N3, I think, in effect(?). I meant only that it 
isnt enough to just have a single uniform notion of 'nest' or 
'context' with no way to distinguish one from another.

>You can use an external
>triple to connect another resource to a nesting.

Yes. I am calling this external triple the nest. I think we agree on 
everything but terminology. ...

> You could say they
>were daml:equivalentTo each other. But they wouldn't be the same thing
>in the language.

...but now I am not sure. What things wouldnt be the same thing, and 
in what language? [Later. You mean the resource and the nest(ing) 
wouldnt be the same? Yes, I agree. I don't see the triples inside the 
nest as being resources. ]

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

Triples with addresses, I guess, yes. But then don't RDF triples 
already have addresses in this sense? (If not, how do the RDF 
graphical pictures ever make into connected graphs?)

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

OK, but then that would seem to require that simple RDF triples also 
would need a nest around them to get asserted, and I was trying to 
allow single undecorated RDF triples to be assertions without 
changing them, given the clamour for this on the various mail threads.

>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

Yes, precisely. (Well, _g4 in the last line.) If one were to take 
apart the KIF, those would be the cons cells in the LISP 
datastructure, labelled with their addresses. (Well, not exactly. 
LISP manages with pairs rather than triples, and so would need 2 cons 
cells for each of these RDF pieces, but the general point is the 
same.)
>
>( ... tim thinks     {  {?x a R}  kif:implies {?x Q (a b)}  } kif:forall ?x.
>)

OK, to each his own favorite syntax.

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

Im sure there is a better RDF way of plugging such holes. I was 
improvising at this point.

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

No, the idea is that if you were to start with, say , a conjunction, 
then etc. would go on adding conjuncts, if you start with a 
relational atom then it goes on adding arguments, and so on. Whatever 
you are listing, it makes the list longer with more of them. You know 
you are at the end of the list when the third item is anything other 
than an etc-triple.

This is a bit like the 'row variables' in SKIF, which range over any 
finite row of anything, but the things must be all the same type. If 
you start with a(n untyped) container, then etc can add anything that 
would fit into the container. This works for anything except etc 
itself (though of course it would be OK to put a string "etc" in if 
strings were in your, er, bag.)

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

Well yes in a sense, though in practice the eval-stopping quote 
usually does a pretty good job of distinguishing them in actual code. 
In the scheme I had in mind, the 'outer' triple's relation name would 
be an explicit label of a list datastructure, which would be a 
container type in RDF, I presume.

The 'nests' are like LISP lists, but they wouldn't be RDF lists, in 
general. LISP is deliberately ambiguous on this point, since it sets 
out to be self-applicable; but even there an Sexpression being 
interpreted as code only 'looks' like a list to the interpreter. (In 
principle one can write self-interpreting code and so on. Sure, and I 
can pat my head and rub my tummy a the same time.)

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

That is one way to go, certainly, though it smacks of logic 
programming in that it has to give the list a name. The nests I was 
thinking about would be (anonymous) syntax.

>
>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 seems to come out as similar to what I was suggesting, except 
that this uses the second argument as the cdr and I was using the 
third one, and this has the list arsy-versy.

I feel a bit nervous about coding everything into function calls. It 
can be done, but if those really are taken seriously as functions 
(and to be really general they need to be) it incurs a horrendous 
runtime burden. Every function call needs to mess with environments 
and continuations, since one may be passing functions as parameters 
to other function calls. Compared to this, address pointers are a 
small price to pay.

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

Right, or
[RDF:list a [etc b [etc c nil]]]
or even better, I reckon,
[RDF:list a [etc b c]]
without the nil. The only place you need a 'nil' (or a 'dummy') with 
triples is when you have just one thingie in the container, and you 
have to plug the last gap with something:
[RDF:list a nil].
LISP needs nil since it uses unlabelled pairs, so has no other way to 
signal an end-of-list condition, but we have a richer diet.

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

If I follow this, it seems like currying, ie treating f(A,B) as f(A) 
(B), where f takes A and produces a function which takes B as 
argument. That works, but it seems burdensome compared to giving a 
list of arguments, since you have to give names to all these 
intermeidate functions, and you need an environment stack to keep 
track of them at runtime.

Also if you try to write a *definition* of 
isAFunctionWhichIncrementsBy, I bet you will finish up using "plus" 
somewhere. :-)

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

Not an RDF meaning, though, surely (?)

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

It wouldnt be either true or false; it would be meaningless, since 
"forall" isnt a relation.

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

OK, that is the part of N3 that I have never been able to understand. 
That seems to be simply impossible. For example, disjunction isn't a 
relation between its disjuncts. It just isn't: so how can an N3 
disjunction possibly be simultaneously RDF-kosher and also 
N3-correct? What can 'OR' possibly mean to RDF? There isn't anything 
in the RDF world to correspond to disjunction (or universal 
quantification, etc.)

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

Well, it could if it knew what to do, but by hypothesis (?) it 
doesn't know what to do with it if it is, say, KIF.  Certainly, if 
RDF assumed that [Kif:universalSentence ?x [...]]
meant that a relation called 'Kif:universalSentence' was true of two 
things called '?x' and '[...]' , then it would be very confused.  I 
don't really see how RDF could make any sense of N3, either.

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

You could......but how would you know that the top 'etc' was a 
continuation of a bag? I tend to think in the address-chain model, 
where it is easy to get from the 'outer' structures to their inner 
ones, but may not be so easy to get back. (Jonathan's recent 
suggestion for quads would provide a 'way back', however.)

>But these triples are not statements.  They are objects.

They are parts of expressions of the higher-level langauge. The 
expressions of any interpreted langauge are just objects at 'lower' 
levels.

>As well of having predicates whic assert something is(sky, blue)
>we have predictates with construct something bag(apple, orange).

True, this does rather mush together constructors and relations. But 
then you can always do that, ie you can think of a container as an 
assertion that a (more abstract kind of) container exists. For 
example, in KIF, where the expressions are lists, the way you 
'construct' a list is by asserting something like: (list a b c d). 
You can read this as saying that a 'platonic' list exists with those 
four things in it (the official semantics) or as just being the 
actual list, a real datastructure, staring you in the face with 
'list' written on it in case you forget what it is. Is 'list' a 
function or a constructor? Only KIF's hairdresser knows for sure.

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

That is one way to look at it, but its not really new, since it is 
good old assertion, made a bit more explicit.

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

Well, I would implement a sugared syntax without explicit 'etc' first 
thing, so one could write

[kif:and [is sun out][is sky blue][is grass green][talks me backwards]]

without all the etcs. It would be etcrified under the hood, of course.

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

That would be the neatest way of doing it, if people thought it 
acceptable. It seems a bit non-RDF-ish somehow, relying on a metadata 
schema to decide syntactic issues, but if that is felt to not smell 
too bad then Im sure it could be made to work very nicely. I guess 
that there could be a kind of RDF-oriented default that said than in 
the absence of any metadata, all triples belong to the RDF engine.

>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 ;-) **

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

Aaarr, these young whippersnappers nowadays don't know what it was 
like when bits cost about $1.50 each and had to be hand-woven. Why, I 
recall having to crank-start the old KDF-9 when the frost was still 
thick on the disc platters.....

---------------------------------------------------------------------
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 Thursday, 7 June 2001 00:06:29 UTC