Re: [OEP] minutes of 5/26 telecon - Naming the 3rd Use 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.

Fixed -- thanks

> [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.

Mike, you are welcome to go ahead and do it if you have time  
(assuming Alan agrees). I guess I am not particularly motivated to do  
it myself since I don't see much of a difference. I don't completely  
get the point of what exactly you want to add or how you want to  
restructure. Whatever the restructuring, the information describing  
the use case and the solution (basically the first paragraph of each  
use case) should also be present in each case, even if it also shows  
up in summary in the end.

> 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?

Seriously, is it that important whether we call it a use case or an  
example? I think having too many levels of distinctions ("Pattern 1,  
use case 1, example 2") will get confusing for other reasons. Purists  
in the task force (I know there are some :) will then justifiably ask  
what is the real difference between an example and a use case and how  
do we distinguish it :)

> 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]

I think we already have an alternative solution for this, don't we?

Natasha

Received on Friday, 27 May 2005 00:12:18 UTC