Building on RDF

   [Geoff Chappell]
   Isn't that because rdf is just the first step/layer? RDF has no mechanisms
   to handle variables, quantification, implications, etc. (and so as a
   knowledge representation language it's not particulary expressive.) But
   wasn't that always the plan? My understanding of the rdf roadmap is that RDF
   will serve as a triple-based data model for storage of facts -- with
   reification just a convention to store "preparsed metafacts" that will only
   be given meaning by a processor/logic system higher up in the chain (i.e.a
   system might have a rule:  infer {?a ?b ?c} from {say john {?a ?b ?c}}). So
   much of the argument/confusion about reification seems to stem from the fact
   that it's pretty useless without another layer (and the fact that it tries
   to do too much/has overloaded meaning - with bags, etc.).

   Do others see it differently? is rdf trying to become a fully expressive
   knowledge representation language -- a la kif -- in and of itself ?  There
   seems to be so much blurring at times between the rdf triple model, its xml
   serialization, and the logic layer(s) that act upon it. I worry that if
   those layers aren't kept distinct (at least conceptually) poor decisions
   will be made about where functionality belongs.

I don't know if RDF should become a fully expressive language.
However, as has been said before, there are good reasons to make it
extensible, and the use of the layering mechanism you speak of is
essentially an admission that it is *not* extensible.  The best we can
do is use RDF to describe the syntax of another language.

Very expressive languages are not necessarily a good idea.  But it's
hard to do without some basic things, such as representing both
p and (if p q), so that, e.g., some inference module might conclude
q from them.  As RDF stands, the obvious way of representing (if p q)
has the drawback that we could infer p and q from (if p q) alone,
because RDF allows the inference of all the triples of a formula from
any formula containing them.  To get out of this bug, we seem to have
three choices:

(a) Use RDF to describe another language entirely.  So instead of
writing p and (if p q), we would write <I, assert, "p"> and
<I, assert, "(if p q)">, and let the processor for the described
language worry about putting these two formulas together.

This is a fine option; it has the great advantage that it would allow
us to forget RDF is there at all.  However, of the people who
occasionally seem to espouse it, most also spend time espousing a
variant in which we can abbreviate <I, assert, "p"> as p in the case
where p is just a conjunction of RDF triples.  This makes sense only
if what they really want is option (b).

(b) Pretend that there is some kind of mysterious semiquotation going
on in crossing the boundary from (if ...) to the occurrences of p and
q inside the (if ...).  This sort of "quotation" is not really allowed
to insert arbitrary strings or even arbitrary XML into a formula,
because anything quoted must be "de-quotable" back into ordinary RDF.
In other words, the whole device is just a gimmick to block inferences
we don't want.

(c) Take option (b), but without the gimmick.  In other words, change
the rules so that you *can't* infer all the triples in a structure.
This idea has encountered strong resistance, partly because of
cultural clashes, but Jonathan Borden's proposals look like they may
be palatable to all cultures concerned.  He preserves the idea of
collapsing the net to a set of node-edge-node triples, but turns them
into septuples by adding in enough contextual information that it's
easy to see how things are scoped.

                                             -- Drew McDermott

Received on Friday, 1 June 2001 16:47:49 UTC