- From: Uschold, Michael F <michael.f.uschold@boeing.com>
- Date: Thu, 26 May 2005 17:34:08 -0700
- To: "Natasha Noy" <noy@smi.stanford.edu>
- Cc: "Christopher Welty" <welty@us.ibm.com>, <public-swbp-wg@w3.org>, <rector@cs.man.ac.uk>
-----Original Message----- From: Natasha Noy [mailto:noy@smi.stanford.edu] Sent: Thursday, May 26, 2005 5:12 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 >> 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. MFU> Let me know when you have a next good draft after all the dust settles, and I will try and play with it a bit. --- > 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> It is more than just calling it an example instead of a use case. In my suggestion, you would remove all the text that tried to characterize in general terms the differences between the two cases, because [IMHO] those differences are too subtle for most readers (including me). If just presented with two examples, there is no expectation that the reader will want to puzzle out any general abstractions about the differences between the examples, or to match the examples the abstractions currently presented. Sinced this is Alan's distinction [I think], it would be nice if he was able to comment. === > 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? MFU> Yes for the title. I was recommending that we use the phrase 'event or situation' in the text defining the use case. === Natasha
Received on Friday, 27 May 2005 00:34:54 UTC