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

> >   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. ...
> 
> Maybe you're just not used to this kind of modeling?  I see no
> difference between this example and mine.

I will try to be clearer about the distinction: in the example you gave,
I can point to object a, and ask: what is its colour, what is its size,
what is its flavour, what is its price? Each of these questions can be
separately asked about the object because in each case we are talking
about a single attribute that is associated with the single object. In
the table format, the first column refers to the object, and each
successive column refers to one attribute of the object in the first
column.

In the cinemas table, the Globus cinema is not an attribute of the month
of April, nor is the film Gladiator an attribute of the month, etc.
Moving around the columns will not help here either, because the cinema
is not an attribute of the film, nor is the month, and so forth. 

If you do want to speak of attributes here, you must assign them to
tuples: you _can_ meaningfully ask "what film is showing {in April, in
Tel Aviv, in the Globus cinema, in theatre 1} and get a clear answer:
"Pokemon 2", and then it does begin to resemble your example of the
objects with colour, size, and so forth. But then the assignments are to
tuples, not single atomic objects, and do not form natural ground atom
triples. And this way of viewing the table is not unique either -- there
could possibly be other attribute assignments to other types of tuples.

 
>  Your table looks to me like
> a simple list of 18 bookings with five of their properties selected as
> columns. 

Yes, sure, but then one needs to invent this new resource called
"booking" that is outside the resources listed in the table, and
uniquely label each of these new resources for each row in the table. If
that does not bother you, fine, I don't mean to beat this to death, just
point out that you need to take this step "outside of the original
vocabulary", be clear about what you are doing, and add this level
inside the syntactical vocabulary you are creating.


Cheers,

Ziv