- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Thu, 15 Sep 2005 11:46:39 -0400
- To: "Natasha Noy" <noy@stanford.edu>
- Cc: "swbp" <public-swbp-wg@w3.org>
Hi Natasha, I enjoyed the n-ary relations draft[1]. I have only one substantive comment. I think it is important to point out that in some (many?) cases, instances used to represent n-ary relations *should* have distinguishing names, and that using blank nodes instead is a potential design pitfall. In section "Considerations when introducing a new class for a relation", the first bullet points out: [[ In our example, we did not give meaningful names to instances of properties or to the classes used to represent instances of n-ary relations, but merely label them _:Temperature_Observation_1, Purchase_1, etc. In most cases, these individuals do not stand on their own but merely function as auxiliaries to group together other objects. Hence a distinguishing name serves no purpose. ]] However, I think the Purchase example is an excellent illustration of a case where the instance *should* have a distinguishing name, i.e., each purchase should have its own URI so that other documents can refer specifically to that purchase instance. Later, when the buyer and seller are discussing the transaction -- for example, if the order wasn't received when expected -- then they can easily and unambiguously refer to it. If the instance does not have a distinguishing name, then less convenient, direct and efficient means must be used to refer to it. To summarize, my points are; 1. In some cases, instances used to represent n-ary relations *should* have distinguishing names (URIs) -- not blank nodes. 2. The Purchase example is a good illustration of such a case. 3. Using blank nodes in such cases is a potential design pitfall. Does this make sense, or have a misunderstood something? Reference 1. http://smi-web.stanford.edu/people/noy/nAryRelations/n-aryRelations-2nd- WD.html David Booth
Received on Thursday, 15 September 2005 15:47:49 UTC