Re: comment (non-member) on N-ary relations

Dear John,

Thank you very much for your thoughtful review! Here are some  
thoughts on your comments.

> (1) ABSTRACT: “...more than one individual or value. These  
> relations are called n-ary relations.”
>         This is purely stylistic, but... really, unary and binary  
> relations are also n-ary relations (n=1, n=2). So even though I  
> understand this has become the "loose" usage in some (database)  
> circles, I think it's more appropriate to call these “multinary  
> relations” (some people use “polyary”, but I don't like that; the  
> “multi-” prefix is  in keeping with the Latin-derived pattern set  
> by unary, binary, ternary,  etc.) You could also call them “(n>2)- 
> ary relations.” Or “relations of arity >2”.

Technically, you are absolutely right of course. However, I think  
most people would understand what we mean hear, and using any of the  
titles you suggest make it sound much more cumbersome (and, perhaps,  
quite a bit less clear for many). Thus, I would still stick with n-ary.

> (2) USE CASE EXAMPLES
>         I think it's a shame to leave out the most classic example  
> of all (and the one that in my experience most reliably produces  
> insight): namely the between relation. How about an example like:  
> “New York is located between Boston and Philadelphia” or “2 is an  
> integer with magnitude between 1 and 3.”

Yes, this suggestion has come up before. The only reason we haven't  
put in originally was our oversight. The reason we are reluctant to  
put it in now is a very practical trade-off: we can't put it in  
without taking it through all the examples, diagrams, pieces of code,  
etc. If there is an overwhelming feeling in the group that adding  
this example would indeed make the document considerably more clear  
and "bring it home" a lot a better, we will do that, of course. If it  
really won't change much, I'd rather save the effort ;)

> (3) PATTERN 1: “Christine has a breast tumor with high probability.”
>         First of all, this is a wonderfully thought-provoking  
> section, congratulations. But a suggestion: You've specifically  
> chosen an example of a relation modified with a probability. While  
> I love the boldness of this, I think the example is infelicitous.  
> For the unsuspecting reader, it could conflate  issues of  
> representational best practice in RDF-OWL with tough issues of how  
> to implement probabilistic reasoning in description logics. You  
> leave yourself open to the objection whether this particular  
> representation pattern is really suitable for use in construction  
> of knowledge-bases upon which automated probabilistic inferencing  
> will be performed. (To which, I think, the most honest answer is,  
> “Nobody knows”;

Actually, I think the answer is "definitely not" -- for that, you  
will need something considerably more elaborate.

This is a good point -- we should add a clear statement, that we use  
probability here only as an example, and don't suggest any "best  
practices" in representing probabilities

> since we really don't know how probabilistic extensions to  
> description logics will best be implemented on the Semantic Web. In  
> fact, if I were making a public OWL ontology today that included  
> probabilistic info, I'd probably use an annotation property.)
>
> There is also the related but intellectually prior objection, that  
> the meaning of probability has multiple possible formal semantics.  
> So it would take more explanation to indicate what formal sense of  
> “probability” was intended here; and hence by reason of this  
> vagueness, it’s not an apposite choice as a paradigmatic example  
> for any particular representation alternative.
>
> But I can think of alternative, less controversial examples of  
> semantically modifying a relation with this pattern. Look at it  
> this way: this pattern could be understood as an RDF/OWL-style  
> formal language replacement for the natural language (NL) adverb  
> construction. In NL, adverbs specialize or restrict verbs. The  
> owl:objectProperty can be thought of as loosely analogous (in some  
> situations) to the verb in a natural language sentence. OWL doesn’t  
> seem to “like” the idea of modifying owl:objectProperty with other  
> properties (i.e. while you can define an owl:objectProperty that  
> has a domain of owl:ObjectProperty—in effect constituting an  
> “adverb slot” on a property—this offers no obvious---to me--- 
> advantages over simply using the OWL-native strategy of just  
> defining a subproperty).
>
> By contrast, this pattern might be a reasonable alternative to  
> subproperties in certain cases where NL would tend to resort to an  
> “adverb”. For example, suppose you wanted to reason about a world  
> that included facts like:
>
>      ”Conrad is flying slowly to Zanzibar with Jimmy.”
>      ”Dave is driving to Abilene with Gene.”
>      “Ed is driving slowly to Butte with Howard.”
>      “Frank is driving at breakneck speed to Cucamonga with Izzy.”
>
> One way would be to define properties isDrivingTo and isFlyingTo  
> with domain Person and range Place, and then subproperties  
> isFlyingSlowlyTo, isDrivingSlowlyTo and  
> isDrivingAtBreakNeckSpeedTo. You’d still have to come up with a way  
> of representing the passenger relation. You could define a second  
> property isTravellingWith with domain and range Person, but that  
> seems to introduce some semantic redundancy that invites mismodelling.
>
> A very reasonable alternative is to nominalize or “gerund-ify” the  
> verb (recall that a gerund is noun formed from a verb, typically  
> using the “-ing” ending) and represent this way:
> <image003.png>
>
> <image006.png>
>
> <image009.png>
>
> <image012.png>
>
> These examples are very close in spirit to Example 1, but they  
> avoid the complications of using probability. They also show how  
> this pattern can circumvent a “combinatorial explosion” of  
> subproperties by allowing re-use of the hasSpeed property and its  
> associated value partition.

I agree with your second point (about circumventing the combinatorial  
explosion) -- and we should perhaps a paragraph discussing this. I am  
afraid that the idea of using speed won't much less controversial  
than probability in some quarters :) One may interpret this as some  
suggestion on representing temporal information, and of course we  
don't want to do this in this note. I hope that the disclaimer that  
we are *not* trying to make any suggestions on how to represent  
probabilistic information, would be an acceptable compromise.


> (4) USE CASE 2:
>         This one is very similar to Use Case 1, but I agree that  
> it’s distinguishable. In fact, I think it’s the most familiar and  
> broadly applicable of all the use cases presented, and I’d give it  
> first priority in the exposition. For example, Christine has  
> severe, terminal pneumonia with multiorgan failure could be  
> represented many ways, but one (by my lights) good one would be to  
> interpret it as: “Christine’s got disease situation going on: it’s  
> pneumonia, it’s multiorgan failure, it’s severe, and it’s  
> terminal”. So it's a kind of pattern that will get used all the  
> time in actual knowledgebases.
> <image015.png>

Well, priority is subjective (as we learned in working on this note).  
Plus, we are not giving any explicit priority to any of the use case.  
One can also argue that the second use case is actually more  
straightforward to represent, and most people reading the note would  
probably look at it because they had trouble with a situation similar  
to use case 1. This is of course also subjective, but I think that  
however we change the order of use cases, there would be a good  
argument to changing it to something else.

>
> (5) USE CASE 3: Considerations when introducing a new class…
>         In the diagrams, you use the “_:” notation in the  
> “aggregating” node. This suggests these should be implemented as  
> blank nodes. You address this, where you say “we did not give  
> meaningful names” to them. Then at the end of the draft, just  
> before the notes, you then add some more discussion of this issue  
> in “Anonymous vs. named instances in these patterns”. These two  
> sections do not quite make the same suggestions, and ought to be  
> reconciled and merged into a single discussion, in my view.

Excellent point -- we'll make this more clear.

> (d) At the very end of the draft where you discuss the utility of  
> blank nodes, you say that blank nodes would be appropriate for  
> cases where you want to indicate equivalency. But I disagree; by my  
> lights, that would actually be a great case for named nodes,  
> because then you could explicitly state an owl:sameAs relation  
> among several such nodes.

I think the difference here is between stating equivalence and having  
an inference engine infer it.

Thank you again for your comments!

Natasha

Received on Sunday, 10 July 2005 21:04:48 UTC