RE: [OEP] minutes of 5/26 telecon - Naming the 3rd Use Case

See inline comments.

Mike


-----Original Message-----
From: Natasha Noy [mailto:noy@smi.stanford.edu] 
Sent: Thursday, May 26, 2005 4:04 PM
To: Uschold, Michael F
Cc: Christopher Welty; public-swbp-wg@w3.org; rector@cs.man.ac.uk
Subject: Re: [OEP] minutes of 5/26 telecon - Naming the 3rd Use Case


Mike,

On May 26, 2005, at 3:33 PM, Uschold, Michael F wrote:

>
> In trying to think of a better name for Use Case 3, I tried to
> identify
> the essential similarities and differences between the three use  
> cases,
> and then to think of names that consistently and accurately refer  
> to the
> core aspect(s) that distinguish each case.
>
> First a question to the authors: For pattern 1, use case 1, do you 
> really mean to only have 1 additional attribute, or could there be 
> several? e.g. you might include the person making the diagnosis. The 
> latter seems more likely.

It is certainly the latter. 
There is a parenthetical note to that  
effect in a paragraph after the first figure in the section called  
"Representation patterns".
[MFU] OK, good, then  'attribute' needs to be plural in the name.
===
>
> I propose the following as a structure for presenting the use
> cases, the
> goal is to make clear the essential similarities and differences among
> the approaches.
> The three different use cases should focus on two main things that
> differentiate them
> 1.    when they arise
> 2.    what you actually do to represent them in OWL - the details
> focusing on variations of the common core.

Hmm... It seems to me that the information is already there. How  
these arise is in the preamble and in each use case we describe the  
details of how you represent it. Is there additional information you  
are suggesting to add?

[MFU] Yes the information is there, I did not add anything, just pulled
it out of the text. My suggestion amounts to making the format of the
presention more structured to it is more immediately obvious to the
reader. Have mini-section heading names: when to use it, and what to do.
Maybe a the end, as a summary?  I believe it would make it much easier
for readers to compare/contrast the approaches. I found it was a lot of
work to do it. 
===

> NB: this is very similar (identical?) to the first one. Basically, I 
> only replaced the word 'attribute' with 'aspect'. These words are
> mighty
> similar in meaning.  I don't get the essential difference between
> "additional attributes describing a relation" and "different  
> aspects of
> the same relation". Can you explain it?
> I guess this means I disagree with or don't understand the claim that:
> "In most intended interpretations, this instance of a relation  
> cannot be
> viewed as an instance of a binary relation with additional attributes
> attached to it."
>
> There might really be a good clean distinction between these two use 
> cases, but to me it is fairly slippery, and I still don't quite see
> it.
> If it is this slippery for me, then it might be difficult for less
> knowledgeable readers?

Yes, the sentence you quoted describes the difference. The two use  
cases are close, but in one case, you really have a binary relation  
with additional information about it. In the second, you cannot  
actually say which one of the two values is "more important" -- you  
can think of this as a "multi-valued" value.

[MFU] Hmmm. This is an extremely subtle point which I'm not sure I get,
and if I do, I'm not sure how important it is to make the distinction. I
guess my view is that these are too close to pull out as separate use
cases. Maybe better to call them two different examples of the same use
case?  
Then you could add the between example as another example of the last
use case? Not necessarily the full example with code an all, but the
gist of it. .
What do others think?  
====

> So, what to name the last use case?
>
> The only thing that distinguishes this from the first two is that
> there
> is no distinguishing participant in the n-ary relation. That's it. So,
> somehow the name should indicate that. Ideally, the names of the other
> two should also reflect that issue, but that would result in awkward
> names.
>
> My suggestion for the last one:
> "Multiple aspects of a single event or situation, with no
> distinguished
> participant."

This is fine, except I would replace "event or situation" with  
"relation" or something else that is sufficiently general -- the  
between example to me is neither an event or a situation (at least  
for people with little background in KR).

MFU: I don't get this at all. I have a little background in KR and I see
the state of affairs of a being between b and c as a situation (in
general parlance).  My cube-mate, John Thompson tells me that Cyc uses
the term 'situation' for the sufficiently general case that includes
both examples. Do you think the intended readers will be confuse by
this? Should we use 'state' instead?

I like using the phrase "event or situation" in the definition of this
use case, and that the purchase example and the between example
illustrate both cases very nicely.

What do others think about this situation? [pun inevitable]
===



Natasha

Received on Thursday, 26 May 2005 23:57:16 UTC