Re: Nests and abstract syntax: Quads vs. nests as sets of Triples

>
>... 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."
>
>So the top level statements are those who are not pointed to by other
>statements in the same nest.

By any other statement in ANY nest.

>Assuming the subgraph described by a nest is
>acyclic, this works. correct?

Right. I had forgotten the acyclic requirement. This really is 
exactly like the garbage collection problem in LISP, it now occurs to 
me.

The 'issue' I raised amounts to the observation that in order to make 
this work, you have to know when you have found all the other 
statements. So RDF triples now, in this scheme, are not really seen 
in isolation, but have a status relative to their containing set 
(bag?) of triples. BUt maybe, particularly since so many people on 
this list seem to want to talk about 'contexts' of one kind or 
another, we should just accept that triples are somehow located 
inside these things, and move on.

> >
> >    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.
>
>The label is a URI -- at least in the abstract syntax we are discussing as
>I've constructed it (subst "nest" for "context")

Oh. Well, I had in mind something more like a syntax label. If 
something like "Kif:universalSentence" counts as a valid URI, then 
I'm happy.

>
> >
> >    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.
>
>I think the implication is that (like a daml:collection) the expression
>
>(or a b c) is expanded to
>
>[or a [etc b [etc c nil]]]
>
>whereas
>(or (and a b) c d) becomes:
>
>[or [and a b][etc c [etc d nil]]]

Right, exactly. Just like Sexpressions.

>perhaps we can use the "." to represent the "etc" and subst "" -- as opposed
>to nil for
>
>(or a) i.e.
>
>[or a ""]
>
> >
> >    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:
>
>The abstract syntax strawman proposes the "atom" which has the following
>EBNF
>
>atom ::= quantifiedVariable | URIreference
>quantifiedVariable ::= '?' Name
>
>URIreference, alternatively QName, as defined by RFC 2396, alternatively XML
>Namespaces -- each of which use EBNF.
>
>a triple, in the abstract syntax, has values which are atoms not necessarily
>URIreferences. This allows, for example, one to encode RDF queries (e.g.
>Squish) as well as formulae.
>
> >
> >    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.
>
>i agree. see above.
>
>This is getting much better. Can we do this all with 4-tuples:
>
><predicate,subject,object,nest> where each are atoms.

That would do fine. It amounts to having a backward pointer from 
nestlings to their nests, and top-level assertions would presumably 
have 'top' or some such indicator in there (or it could be the RDF 
'context', as long as RDF can clearly recognize its own contexts.)

>For the hard core triplers

That phrase suggests a category of immoral activity which transcends 
merely biblical prohibitions.

>we can alternatively say:
>
>There is a set of Nests, each nest is a set of triples.
>
>:-))
>
>I am headed off for a day, but will be back friday.
>
>-Jonathan

---------------------------------------------------------------------
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 Wednesday, 6 June 2001 17:08:06 UTC