OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsdm] Relations


I wonder why we are trying to re-invent the wheel when there is a 
perfectly good and well thought out modeling paradigm for associations 
in UML. What is it that we are trying to achieve here that cannot be 
done using the UML notion of associations with role names associated 
with each end of the association? Enquiring minds just want to know I 
suppose.

Thanks,

Jishnu.

Homayoun Pourheidari wrote:

> Mark, Let me try to use your words...  Please see below.
>
> Cheers,
> H.
> ---
>
>
> Potts, Mark wrote:
>
>> Homyoun,
>>  
>> So I guess I see it differently  - member relationship s are seen in 
>> three ways from either side of the relationship  - Adam is my Father 
>> (John's perspective), John is my son (Adam's perspective) - or from 
>> the perspective of the relationship itself (I think this is what you 
>> are getting at). so from the perspective of the relationship what is 
>> that between John and Adam?
>
> child is an instance of an association (or relation) between john and 
> adam.  parent is an instance of an association (or relation) between 
> adam and john.  That is the perspective of the relation.  I am an 
> association between two or more participants.  One association allows 
> one participant to play a "child" role and another association allows 
> the other participant to play a "parent" role.  It is through the two 
> associations that the roles are established.
>
>>  
>> The association is not parent or chid  - they are the roles the 
>> participants play in the association - unfortunately in the example 
>> the the association is "*relation*" (overloaded here but meant in the 
>> in the family sense) - i.e. these two people are *related*. Having a 
>> ternary association here makes no sense because there is a types 
>> association between each distinct member (whether that be general, 
>> parent child or specific, father mother son daughter). If you want to 
>> have a group relationship them that would be a containment model, say 
>> *family* (where the members are all listed). This is why service 
>> Groups in my mind have to be reworked to be a containment model using 
>> relationships not something separate.
>
> I think what you're saying here is that associations are only binary.  
> If so, I believe that as far as the association instance is concerned 
> it can be defined  for use by two or more participants.  It all 
> depends on how you define the semantics of the association instance 
> (or role).  For this particular example that we're looking at here, 
> child/parent, the associations should be binary.  However, I already 
> gave an example of an association which is not binary. 
>
> Nonetheless, for the sake of simplicity, I am not opposed to keeping 
> associations strictly binary and using a group model to providing the 
> "family" or more than binary relations.  I think that works for the 
> use cases that I have looked at as well.  But I believe Andrea had 
> some use cases where she thought a service group "family" model does 
> not quite work.  I am waiting to see them before tightening up my 
> opinion on this..
>  
>
>>  
>> Mark
>>  
>>
>>     ------------------------------------------------------------------------
>>     *From:* Homayoun Pourheidari [mailto:homayoun@bea.com]
>>     *Sent:* Tuesday, August 10, 2004 9:52 AM
>>     *To:* Potts, Mark
>>     *Subject:* Re: [wsdm] Relations
>>
>>     Mr. Potts, long time no hear...
>>
>>     Ok.  So in the example that I gave, child and parent could be
>>     instances of an association class with the name of the instance
>>     set to "child", "parent", "mentor", or "abuser!" for that
>>     matter.  "MakesUseOf" is in effect a reference that is
>>     established between the managed resources and the relation or
>>     association instance. 
>>
>>     As for support for more than binary relations, the last wsdm
>>     discussion we had on relations was centered around support for
>>     binary relations and as such I positioned my examples that way. 
>>     However, one can just easily support ternary (or more)
>>     relationships by returning triplet values.  For example running
>>     getListOfParticipants on a relation like "works with" can
>>     return((a,b,c) (d,e))  meaning that a,b, and c have a ternary
>>     relation and d and e have a binary relation.  For the first case
>>     though (a,b,c) we will have to decide what the target value of
>>     getRelationships() on "a" should be?  Is it b or is it (b,c)?
>>
>>     Cheers,
>>     H.
>>     --
>>
>>     Potts, Mark wrote:
>>
>>>     Ahhhh....... but isn't parent a role of a person and is only
>>>     created by the association that exists - I think so.
>>>      
>>>     John has a relationship to Adam, but there can be many
>>>     relationships that could exists (parent, mentor, abuser!). The
>>>     association is made and then the association has
>>>     characteristics. What this means is that the relationship is an
>>>     association class that has references to the two or more members
>>>     in the relationship and those members are identified in a
>>>     particular role they play in that relationship.
>>>      
>>>     Go take a look back at WS-Manageability  - I think someone wrote
>>>     some pretty good stuff on relationships there :))
>>>      
>>>     Mark
>>>
>>>         ------------------------------------------------------------------------
>>>         *From:* Homayoun Pourheidari [mailto:homayoun@bea.com]
>>>         *Sent:* Monday, August 09, 2004 6:01 PM
>>>         *To:* wsdm@lists.oasis-open.org
>>>         *Subject:* [wsdm] Relations
>>>
>>>         Hi,
>>>
>>>         Replying to Igor's request to describe how I think relations
>>>         should be conceptually used with managed resources, I have
>>>         attempted to describe my view using the following UML
>>>         diagrams.  I hope this makes Igor very happy :) 
>>>
>>>         Cheers,
>>>         H.
>>>         ---
>>>
>>>         Essentially, I believe Relations should be considered as
>>>         stand-alone entities and managed resources "MakeUseOf" these
>>>         entities (this is how I am trying to relate manged resources
>>>         and relations without using the word "use").  A manager
>>>         should be able to go to a managed resource and determine
>>>         what relationships (a relation in addition to a target name,
>>>         the source is the managed resource itself)  or go to a
>>>         relation and determine what managed resources "MakeUseOf"
>>>         it.  For example in the following figure: 
>>>
>>>
>>>
>>>         If a manager queries ManageableResource1 and run
>>>         "getRelationships", it should see the tuple:
>>>         (Relation1, Target1) where Target1 is the target of that
>>>         relationship.  Same for ManageableResource2, running
>>>         "getRelationships" should yield the tuple: (Relation1,
>>>         Target2).  Note that Target1 and Target2 maybe the same or
>>>         may not.
>>>
>>>         Now if the manager goes to Relation1 and runs
>>>         getListOfParticipants, it should yield:
>>>         (ManageableResource1, Target1)
>>>         (ManageableResource2, Target2)
>>>
>>>         If ManagedResource1 runs RemoveRelationship(Relation1,
>>>         Target1) the relationship will be removed.  Now if you run
>>>         getListOfParticipants() on Relation1, you should see:
>>>         (ManagedResource2, Target2).  If ManagedResource2 runs
>>>         RemoveRelationship(Relation1, Target2) the relationship will
>>>         be removed but Relation1 still exists, but it's list of
>>>         participants will be updated according (with no participants
>>>         at this point).
>>>
>>>         The Relation entity, should be fully discoverable and
>>>         exhibit information such as properties, operations, and
>>>         notification types (for those that are managing relations
>>>         themselves) and also have metadata and policies that it can
>>>         attach to all of the above information.  In essence, the
>>>         description of a Relation entity is very similar to a
>>>         Managed Resource description in wsdm.
>>>
>>>         Relation "implementations" can be managed resources in the
>>>         same or different domain than the managed resources that
>>>         "MakeUseOf" them.
>>>
>>>         To complete the picture above with a more concrete example,
>>>         consider 5 managed resource, John, Jill, Nancy, Adm, and
>>>         Eve. They have the following relationships:
>>>
>>>             *  John is "Child" of Adam
>>>             * Adam is "Parent" of John
>>>             * Jill is "Child" of Adam
>>>             * Adam is "Parent" of Jill
>>>             * Nancy is "Child" of Eve
>>>             * Eve is "Parent" of Nancy
>>>
>>>         Here is the diagram describing this deployment:
>>>
>>>
>>>
>>>
>>>         Use the templates described above in applying the operations
>>>         that are provided and to render the results.
>>>
>>>
>>>
>>>
>>>
>------------------------------------------------------------------------
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]