Why Triples? (was Re: What do the ontologists want)

> At the risk of being on the receiving end of a hailstorm of flames from
> the regulars on this list, I will toss a spanner into the works here and
> question the use of triples.
...
> Again, I know that these examples can be reduced to encoded triples --
> but is the resulting clumsiness worth it compared to the straightforward
> multi-ary statement? And perhaps more to the point, consider that in
> order to really take off, the SW will eventually have to come into
> contact with the data the world has stored in relational data-bases,
> which routinely make use of reams of tables representing very large
> multi-ary relations. If the industrial world is told that
> uploading/downloading this data through the SW will require painfully
> chopping up the tables into an explosion of triples, waiting for the
> transmission traffic to complete and then reconstituting from them the
> tables at the other end, one may fear that it will recoil in horror.

I had one of these moments a few weeks ago (after working in Prolog
for a while without much sleep), where I couldn't remember why we were
using triples.  I asked several people; thanks to Ralph Swick for
nicely stating what I explain below.

Before I get to that, let me address your reasons against triples.
You argue complexity-for-users and performance, I think.  Those are
very real concerns if people and network-interfaces are dealing with
RDF triples directly, but I'm hoping/expecting they will often be a
level removed.  There's no reason a set of triples like

   <a, color, red>
   <a, size, big>
   <a, flavor, sweet>
   <b, color, green>
   <b, size, small>
   <b, flavor, bitter>

can't be presented to users as

   object   color   size   flavor
   ======   =====   ====   =====
     a      red     big    sweet
     b      green   small  bitter

and a similar approach used for network protocols.  In general, one
can think of the tuple form as the answer to some particular query
about the triple form, I think.

The important thing is just that we know how to map between every
syntax and the RDF abstract syntax (triples).


The best reasons I've heard for triples:

     We don't want to grant any particular properties or relations
     special status.  

If we later want to add a property (column) "price" or even "price at
Whole Foods Market in Newtonville on 2001-05-18" we can do that
without breaking anything.  If you don't know about that column name,
you wont see it.  (Of course there can be some discovery mechanism, if
desired.  My second example column name is itself a tuple of sorts,
too; the triple model makes that natural.)

I see this as kind of like parameter lists on procedure calls.  I'm
going mangle and fail to attribute a classic CS quote: "If you have
more than 4 or 5 formal parameters declared for a procedure, you've
probably forgotten some."  

The basic truth here, I think, is that models of complex relationships
need to be able to evolve.  The triple model means that evolution
means adding rows, not changing our tuple definitions.  But of course
that's a somewhat illusary difference, since as you said n-tuples can
be mapped onto triples.

   -- sandro

Received on Friday, 18 May 2001 15:30:31 UTC