- 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