W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

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

From: Sandro Hawke <sandro@w3.org>
Date: Sat, 19 May 2001 16:22:20 -0400
Message-Id: <200105192022.QAA09679@hawke.org>
To: "Ziv Hellman" <ziv@unicorn.com>
Cc: www-rdf-logic@w3.org
>   sandro:
>   > 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
>   >
>   This is a nice example, but if you examine it closely you will notice that
> it does not represent a true multi-ary relation, but rather a serialization
> of natural binary relations: an object has a colour, it has a size, it has a
> flavour, and each of these is an attribute of the object. In this case, the
> table can be directly reduced to the triples, and vice-versa. Add price to
> the list later, and you have just tacked on yet another binary predicate.
>   But consider the following more complicated table that one might encounter
> in real life and want to make available on a semantic web:
> month      city         cinema  theatre     film
> -------    ----------   ------- -------     ---------
>  April     Tel Aviv     Globus  1           Pokemon 2
>  April     Tel Aviv     Globus  1          Gladiator
> ...
>   Unfortunately, no matter how one views this, there is no way to reduce the
> information content here to binary attributes. In order to encode it as
> ground atom triples, one would probably artificially have to create 18
> objects, each of which would then be associated in a binary relation to each
> basic item in the table. The resulting data construct would look so baroque
> and/or contain so much redundancy that I would guess someone somewhere will
> eventually notice that RDF has containers and decide to ship the table more
> straightforwardly as a list of lists and by-pass the triples altogether.

Maybe you're just not used to this kind of modeling?  I see no
difference between this example and mine.  Your table looks to me like
a simple list of 18 bookings with five of their properties selected as
columns.  If I were in charge of negotiating bookings for a theater,
I'm sure I could name a dozen other interesting columns, like "box
office gross", "payment due to distributer", "tracking number for shipment
which should include the film", ...     Maybe that's not exactly what
each row represents -- I can't tell if one cinema sometimes shows the
same film in two theaters, in two cities, etc -- but it seems natural
to me.  

>   > 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.
>   In the cinemas example above, it is not immediately clear that adding new
> triples somewhere deep in a complicated triple encoding of the data is
> easier -- or less likely to break anything -- than tacking on a new value at
> the end of each list in a list of lists encoding.

What if some columns are only visible to some people?  And some cells
(row/column combinations) have access-control or confidence-level or
reader-language-versions metadata?  As you add important functionality,
it starts to look a lot simpler with triples (which can be displayed &
edited as tables when appropriate, of course).

Learning to model the information with only binary relations may be a
learned skill, but I don't think it's particularly different from or
more difficult than related disciplines.   If you're having trouble
thinking what the class of row-object is (in this case my suggestion
was a "booking"), I wonder what you would name this table in a

(There's an interesting line of thought here: one could implement a
mapping from SQL to ground atom binary relations using information in
the SQL schema.  Unfortunately, I guess some information is missing,
like the semantics of repeated rows.)

    -- sandro
Received on Saturday, 19 May 2001 16:22:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:38 UTC