Re: plural vs singular properties (a proposal)

On Jan 5, 2008, at 12:37 PM, Garret Wilson wrote:

> Frank Manola wrote:
>> Choice #1:
>> Add the tuple [ <...#mybook>  "My Book"  "airplanes" ] to the  
>> relation you have, forming
>> +----------------+----------------+----------------+
>> |      URI       |    dc.title    |   dc.subject   |
>> =================|----------------|----------------|
>> | <...#mybook>   |   "My Book"    | "semantic web" |
>> | <...#yourbok>  |  "Your Book"   | "database"     |
>> | <...#mybook>   |   "My Book"    | "airplanes"    |
>> ...
>>
>>
>> This is a unique tuple (it doesn't duplicate any of the others),  
>> but normalization principles frown on this, because you duplicate  
>> the fact that <...#mybook> has a dc:title of "My Book".
>
> "Normalization principles" don't just "frown on this"---the  
> relational model expressly forbids it. Let me explain.
>
> You say that, semantically, the above relation is duplicating the  
> fact that <...#mybook> has a dc:title of "My Book". That must mean  
> you agree that every tuple with URI=<...#mybook> applies to the  
> same book. This implies that URI is a key---in fact, if you'll look  
> above, I've double-underlined URI to indicate that it is a key. And  
> you can't have multiple tuples with identical keys in a relation--- 
> the relational model "frowns on this". ;)
>
> On the other hand, if URI is *not* a key, then tuple #1 and tuple  
> #3 above do not apply to the same book, and therefore you have not  
> represented the semantics of <...#mybook> having a dc:subject of  
> both "semantic web" and "airplanes".

I don't recall you having explicitly said that the URI column was the  
key of the relation.  But being a unique identifier (of a book in  
this case) and being a key of a specific relation are two different  
things.  I was assuming that the URI uniquely identified the book.   
But to use this 3-ary relation, the key of the relation has to be all  
three columns, which is perfectly legal (I'm assuming you can have  
distinct books with the same title, which actually happens).   That  
is, it's true that you can't have multiple tuples with identical  
keys;  but it's not necessarily the case that the key is a single  
column.

The common parts/supplier database example illustrates the difference:

There is a parts relation, say part(P#, name, weight) with key P#  
(part number).
There is a supplier relation, say suppler(S#, name, address) with key  
S# (supplier number)
There is a supplied_by relation, say supplied_by(P#, S#, quantity)  
that says that part P# was supplied by supplier S# in a given  
quantity.  (A particular part might be supplied by several suppliers,  
and a given supplier might provide several parts).   Now, even though  
S# identifies a distinct supplier, and P# identifies a distinct part,  
the key of this supplied_by relation is the pair (P#, S#).  A key  
doesn't have to be one column;  you use whatever columns are needed  
to insure that the key uniquely identifies a tuple.  (This example is  
clearly simplified, but I hope you get the idea).

--Frank

>
>>
>> Choice #2:
>>
>> Create a normalized design with two relations (tables):
>
> Yes, I'm aware that I can create some normalized relational model  
> to represent any specific set of semantics, including anything  
> representable in RDF. The issue here is a general one regarding the  
> general semantics of the relational model versus the general  
> relational semantics of the RDF model.
>
> Let me address that on the separate sub-thread regarding "one- 
> relation-per-graph".
>
> Cheers,
>
> Garret

Received on Saturday, 5 January 2008 18:08:40 UTC