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

After a brief chat with Evan, I finally actually [think that I]
understand what the distinction is.

For both use cases 1 & 2:
* There is a distinguished participant in the relation, the subject. 
* There are also n-1 remaining participants of the relation

For use case 3, there is no such distinguished participant, period.

What distinguishes use cases 1 and 2 is 
- how we view the remaining n-1 participants in the relation,
- how we view the overall n-ary relation 

Use case 1:
* there is a single distinguished participant among the remaining n-1
participants
* this [second] distinguished participant of the relation is viewed as
the object of a [notional] binary relation. The remaining n-2
participants of the n-ary relation are seen as further modifying the
binary relation, "attributes of the relation", in Natasha's words.

Use cased 2:
* there is NO single distinguished participant among the remaining n-1
participants
* the n-ary relation does not naturally correspond to any notional
binary relation.

What I failed to glean form the text is that there are two levels of
'distinguished' participants for use case 1.

Is this correct? 
Mike

PS: I'm not proposing that these words are good ones for the document,
I'm just wanting to see if we are on the same page.

===================
Mike Uschold
Boeing Phantom Works
425 865-3605
===================


>  -----Original Message-----
>  From: ewallace@cme.nist.gov [mailto:ewallace@cme.nist.gov] 
>  Sent: Friday, May 27, 2005 8:15 AM
>  To: noy@smi.stanford.edu; Uschold, Michael F
>  Cc: welty@us.ibm.com; public-swbp-wg@w3.org
>  Subject: RE: [OEP] minutes of 5/26 telecon - Naming the 3rd Use Case
>  
>  
>  
>  
>  Michael Uschold wrote in the part tagged [MFU]:
>  >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?  
>  >====
>  
>  This is NOT a subtle point for an object modeler, and I 
>  don't understand why 
>  it is so hard for some to see that.  There is a good example 
>  from the Driving Task Decomposition problem that I worked on 
>  with Craig Schlenoff, David Aha, and 
>  others from the robotics side of our lab.  The control 
>  system for this includes a World Model (WM) that holds 
>  information about any sensed objects that may be of 
>  interest.  For this discussion, lets just consider "active" 
>  objects, such as people and vehicles.  These objects will be 
>  in the World Model and they will have attributes for size, 
>  type, position, behavior, velocity or even projected 
>  path.  But the relationship between the controlled vehicle 
>  and these objects is also modeled.  Often characteristics 
>  that exist between these objects are the important criteria 
>  for making driving decisions.  When I created a UML diagram 
>  for the WM, I used an AssociationClass for this relationship 
>  so that characteristics such as velocity, distance, and 
>  minimum_safe_distance between the objects could be 
>  rendered as attributes of this relation.  Note that these 
>  characteristics are only 
>  relevant in the reference frame of the relation and are not 
>  otherwise available in 
>  the model (although they are derivable from it),  thus it is 
>  quite natural to think 
>  of them as "belonging to the relation".
>  
>  A modeler with a relational DB background may tend to think 
>  (because of a 
>  relation-oriented rather than object-oriented perspective) 
>  of this same relation 
>  as an N-ary relation with a joint uniqueness constraint on 
>  the roles for 
>  controlled_object and active_object showing the primacy of 
>  those objects in the relation.  Note that OWL has NO way to 
>  define joint uniqueness (compound keys) 
>  and 95+% of UML users wouldn't even think of doing this, let 
>  alone know the notation
>  in UML for saying it.   Whereas data modeling languages such 
>  as ORM do support
>  ideas similar to AssociationClass in addition to joint 
>  uniqueness constaints.
>  
>  -Evan
>  
>  
>

Received on Friday, 27 May 2005 20:16:12 UTC