Re: Reification as nesting

This is really terrific, pat. I couldn't agree more. I will rework the
abstract syntax proposal to incorporate these ideas. Two points:

1) It occurs to me that the RDF syntax might accept a top level attribute
that indicates to a parser which statements are to be asserted directly as
triples, and which are to serve as the root of an expression that is to be
asserted e.g. This can be easily decided based on namespaces e.g.

rdf:assertNamespaces="log kif" -- prefixes used -- would indicate that
expressions such as:

<kif:forall ...> are indended to be asserted as formulae/expressions (and
the nested triples are _not_ asserted).

whereas

rdf:assertNamespaces="*" provides for the current RDF situation where every
triple is asserted.

2) There seems to be a good amount of overlap between what Drew has proposed
for a reformulation of RDF, what N3 incorporates into the "log" namespace,
and what you are suggesting for the "kif" namespace.

Perhaps this _is_ the logic language LL we are all discussing. Assuming the
"..." syntax works as described does kif require much more?

-Jonathan

>----- Original Message -----
>From: "Drew McDermott" <drew.mcdermott@yale.edu>
>
>It seems to me that whether one "has" to depends on how one is trying to
>"build on top" of RDF.
>If "building on top" means producing a language which will include RDF as a
>subset,
>then one does not need reification to do nesting.  If "building on top"
>means finding a way to convey the semantics of something in the new
>langauge using only pure RDF and a bunch of new special Properties,
>then one needs reification.

Even reification will not do that, in general. (If something is ever
built that can do that, then it will probably use reification, but
reification won't do the job by itself.)  But I think that is all an
aside: we don't need to get to that very advanced stage yet. Just
being able to distinguish subexpressions would be an enormous step
forward.

>
> > The good news is that a consensus is emerging, based on the idea of
> > drawing a line around an RDF substructure with a note saying "Don't
> > automatically infer the stuff in here."
>
>Good!
>
> > The bad news is that there are too many terms being used for this
> > idea, including "context," "nesting," and "reification."
>
>I don't see a conflict between "nesting" (what is going on)
>and "context" (a relationship between one level of nesting
>and the next highest).
>
>Under DanC's influence I have been moving away from [Conceptual Graphs']
>"context"
>as a noun for the thing to "formula". So one formula can be the context
>for another (sub-)formula.

I know I get overly fussy about nomenclature, but "context" is a very
over-used word, with so many meanings that it is almost guaranteed to
be misunderstood. Maybe it would be best to invent a completely
artifical new word. That is why I rather liked "nesting", which is
fairly free of mathematical/logical/linguistic baggage.

But PLEASE let us not call it "reification". I will call it "nesting"
until someone renames it.

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.). Second, nesting needs to be recursive, so that one can
describe subexpressions. That is, a nest might have other nests
inside it.

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

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.

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

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.

This also works for containers, by the way eg
[rdf:bag a [etc b [etc c d]]]
abbreviated by
[rdf:bag a b c d]
which uses fewer triples than the current technique.

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

Received on Wednesday, 6 June 2001 11:28:03 UTC