- From: Sandro Hawke <sandro@w3.org>
- Date: Sat, 19 May 2001 16:22:20 -0400
- To: "Ziv Hellman" <ziv@unicorn.com>
- Cc: www-rdf-logic@w3.org
Ziv:
> 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
database?
(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