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

Drew McDermott wrote:


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

Correct. The issue arises when the RDF 'page' (e.g. as represented by text
or an internal representation of the XML Infoset) is chopped and flattened
into triples. The document hierarchy and element order is then lost.

Assume we have a set of statements Asserted(), what membership indicates is
merely that the statement is the top level statement in a nest and each web
page defines its own nest.

... 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. Assuming the subgraph described by a nest is
acyclic, this works. correct?

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


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

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.

For the hard core triplers 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

Received on Wednesday, 6 June 2001 12:00:36 UTC