Re: [OEP] review for n-ary relations draft

Chris,

Thanks for your comments. Reply in-line.

> 1) The note misses a section on "problems" or "shortcomings" of the 
> approach.  There are two main problems with reification:
>
> a] unitended models: Reification introduces a new notion of identity 
> for relation tuples, making it possible for the same relation (i.e. 
> tuple) to exist multiple times.  For example, it is possible for this 
> model to exist:
>
> Christine has_tumor DR1
> DR1 diag_value Breast_Tumor
> DR1 diag_prob HIGH
> Christine has_tumor DR2
> DR2 diag_value Breast_Tumor
> DR2 diag_value HIGH

I am not sure I see this as a problem (yet). You are assuming that 
identity is somehow implied by all property values being the same. This 
is not necessarily the case in general though, is it? At least there is 
nothing in the language to imply that.

If we did want to say that DR1 and DR2 were identical, why couldn't we 
use owl:sameAs? That should take care of counting, shouldn't it? 
(vis-a-vis cardinality).

> b] Reificaiton creates a maintenance problem if you want to have local 
> range or cardinality constraints on some role in the reified relation 
> that depends on the class of some other role.  You end up having to 
> build a lattice of classes to represent all the possible combinations. 
>  For example, we might want to say that a person can buy no more than 
> 1 book, whereas a company can buy up to 10.  Expressing this 
> constraint requires a special subclass of the reified relation class 
> that represents the combination of range restrictions.  The example 
> becomes a bit lame because of the domain, but there are plenty of good 
> cases for it.

This is a good point and relates to Guus's note on Qualified 
cardinality restrictions [1].

> 2) I realize the issue of whether to refer to this as reification or 
> not was discussed.  I strongly disagree with the conclusion, however. 
>  The solution approaches in the note are both forms of reification. 
>  That there is an existing notion of reification in RDF doesn't change 
> the fact that in the literature, which predates RDF by decades, this 
> is known as reification.  It will take one sentence to separate this 
> reification from rdf-reification and properly orient people so they 
> will know what it is called and can read more about it if they are 
> interested.

Given that the target audience is much more likely to be familiar with 
RDF than with the older notion of reification (just a wild guess), I 
still think it is reasonable not to use reification throughout the 
note. What is missing however, is a paragraph comparing n-ary relations 
as discussed in the note with RDF reification. I was planning to put 
such text in the next draft, and there were some ideas on the list on 
how to do that.

>  3) Reified relations have an ontological status, that would be useful 
> to mention briefly, again for the purposes of orienting the interested 
> reader and giving them a good starting place to read more.  It has 
> been argued that reified relations actually represent the event that 
> caused the relation to come into existence, and taking this 
> perspective actually helps make the usage a little more clear.

If you could write it up so  that it indeed makes the use more clear, 
go for it. I am a bit dubious: for someone who is just looking for a 
practical answer, it may cloud rather clarify the issue. But I'll be 
happy to be proved wrong with a lucid paragraph or two.

>
> 4) The note misses a bibliography.  Again, I think it is important in 
> these notes to let people know that the semantic web did not invent or 
> create these problems, and both the problems and solutions have a long 
> history.

Indeed. We were planning to put it in but never got around to it in the 
first draft. No doubt there is plenty of stuff that we can and should 
reference here.

> I am willing to make these changes and generate a new draft.

Ah, that's always nice to hear :) We were planning to work on the next 
draft some time this months, but I don't want to stop you from putting 
your bits in :) Seriously though, we'll be more than happy to take you 
up on the offer. We can discuss off-list how to coordinate the 
versioning.

Natasha

[1] http://www.cs.vu.nl/~guus/public/qcr.html

Received on Wednesday, 1 December 2004 04:57:54 UTC