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

Good comments, and reply.  A few more brief thoughts.

Mike


============================================
Mike Uschold
Tel: 425 865-3605              Fax: 425 865-2965
============================================



>  -----Original Message-----
>  From: Natasha Noy [mailto:noy@smi.stanford.edu] 
>  Sent: Sunday, July 10, 2005 2:05 PM
>  To: John Madden
>  Cc: public-swbp-wg@w3.org
>  Subject: 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.
  
It would be easy to add a small footnote stating this technical point.

>  > (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 ;)


It would be easy to briefly mention the between example, w/o going to
the trouble of doing it in detail.
  
>  > (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 Monday, 11 July 2005 17:26:53 UTC