Can we agree on triples ?

From: "Drew McDermott" <drew.mcdermott@yale.edu>

> There is no problem with considering triples as S-expressions.  The
> problem is considering them as S-expressions *and* as a formal
> descriptive language simultaneously.
>
> Suppose someone suggests the use of Unicode as a formal language, along
> the following lines.  Let the letter "l" stand for "lives in."  Let
> "W" stand for George W. Bush.  Let "D" stand for Washington, D.C.
> Let "T" stand for Tony Blair, and "L" for London.  Let "t" stand for
> `taller than.'  And so forth.  Make sure every printing character is
> assigned a meaning.  Now take any string and divide it into groups of
> three characters, and assign to "pqr" the meaning "the relation
> denoted by p holds between the object denoted by q and the object
> denoted by r."  The whole string then stands for the conjunction of
> the propositions denoted by the letter triples.  So the string
> "lWDlTLtTW" means "George W. Bush lives in Washington, D.C., Tony
> Blair lives in London, and Tony Blair is taller than George W. Bush."
> Call this scheme URF, for "Unicode Representation Format."

There is a word for that concept ... "supervenience"  ... see Chalmers [1].
But I have a trouble with your example:  the sentences above already
supervene on a coding scheme (let's say it's the English alphabet).  To find
an analogous example you would need to find a coding scheme that sits above
not parallel with that level.

> Now suppose I argue that URF isn't a very powerful language, for
> reasons that I hardly need to enumerate.  It would be frustrating if
> the pro-URF faction comes back with the rejoinder, "What do you mean,
> it isn't very powerful?  You can represent *anything* in Unicode, can't
> you?  Isn't it useful to have a `common exchange protocol'?"

In the process of supervening me thinks the design criteria for going from
one level to the next is to choose a coding scheme that usefully  simplifies
without important loss of information, yet makes the *least* number of
assumptions.  I think the designers of the RDF data model have wisely seen
that triples meets that criteria.

Note,  also, that I used the qualifier term "exchange" when I characterized
RDF as a "common exchange protocol".  I view triples as useful for the
purpose of exchanging information between systems *only*; not as the
internal data model in which the systems themselves operate.  For the
internal data model of systems, personally I would prefer something like
[statementId, subject, predicate, object1, object2, .....] + context
containers; but it really doesn't matter .. let each implementer choose
their own for now ... and let a winner emerge based on proven usefulness.
Or are we ready to standardize that level too?

> In my URF world, couldn't I say
>
>  Inferencing is an application that sits on top of the Unicode ... let the
>  best one win.  I fail to see how this is an argument against simply using
>  Unicode.

Again your choice of a an example has made my argument absurd; if you choose
an appropriate example of supervinece I believe you would agree that it is
not the degenerate case you exemplify.

> The point is that no one is arguing against using Unicode or RDF as a
> coding scheme; the argument is against using either as a formal
> language.  If RDF is simply an encoding scheme, then we can put it on
> the back burner and focus on the language actually being encoded.
> If we view it *as a formal language*, then its flaws loom large.  It
> lacks many key features, including implication and bound variables.

Did I miss something here?  I thought that the RDF triples model *was* only
a coding scheme and has never  purported to be a *formal language*.   But
shouldn't we formally agree that triples *are* the building blocks of any
next level "formal language" before we move on?  Continually bickering about
that will mean that collectively our projects will fragment.

> Actually, I am not convinced that it's such a great encoding scheme.
> I am told it goes beyond XML in some important ways, but I'm not sure
> what they are.

Please don't confuse the coding of triples in XML with the triples
themselves.  I think M&S [2] makes that distinction clearly and even seems
to anticipate that alternative coding schemes should\would emerge.  N3 is
such an alternate proposal, there are others.

> As I have argued before, I don't think it would be particularly
> difficult to fix the problems with RDF.  However, fixing them would
> require thinking of an RDF expression as a self-contained textual
> object, which seems to be incompatible with thinking of it as a piece
> of a graph, and therefore incompatible with the triples model.  I
> think this is where we're stuck.

Well I think we could consider that triples themselves are the only point of
agreement that RDF has established.  And I would agree that anybody who
tries to find a "self-contained textual object" inside of the RDF/XML coding
of triples, will get a head ache .... so don't do it .... take two aspirin
and call me in the morning.

[1] http://www.amazon.com/exec/obidos/ASIN/0195117891/
[2] http://www.w3.org/TR/REC-rdf-syntax/#intro
"It is also important to understand that this XML syntax is only one
possible syntax for RDF and that alternate ways to represent the same RDF
data model may emerge."

Seth

Received on Monday, 2 April 2001 13:55:11 UTC