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
> > >   >
> > > month      city         cinema  theatre     film
> > > -------    ----------   ------- -------     ---------
> > >  April     Tel Aviv     Globus  1           Pokemon 2
> > >  April     Tel Aviv     Globus  1          Gladiator

> 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.=20

> 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.

Ah, yes, of course.  Silly of me not to notice.  In SQL terminology,
the difference is that my table had a single column which was a
primary key.  Your table was near the other end of the spectrum, with
the primary key being a composite of every column.  (Probably the
complete other end of the spectrum is where a primary key can't be
made out of even all given rows; this is the case where a SQL table
will have duplicate rows, I think.)

     -- sandro

Received on Sunday, 20 May 2001 08:08:39 UTC