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

Mike,

yes, we are definitely on the same page here.

Natasha


On May 27, 2005, at 1:15 PM, Uschold, Michael F wrote:

> 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 21:38:17 UTC