Abstraction of the Member_of Meronymy

[jeshaw2]

What would you consider to be a good abstraction of the Member_of Meronymy?

This is another thread in my concers about abstractions of the six types of meronymy.  The first thread of this series is the Part_of Meronymy .  The introductory and Background portions of that thread should be reviewed by readers new to this series.

Now to the Abstraction...A work in progress.

Member / set or group
In this meronymy class fall, for example: tree/forest, student/class.

• parts do not necessarily have a structural or functional relation with respect to the group.
• Parts are distinct from each other.
• Members may belong to more than one group at a time.
• Destruction of the group does not destroy the members. [Policy]
• Destruction of a member does not destroy the group. [Policy]
• The group does not own its members. [Policy]
• The group does not provide space for its members.
• The types of the members do not define the type of the group.
• The constitution of the membership list is dynamic. [Policy]
• Parts achieve membership in one of three ways:  1)  Common values of a shared subset of their attributes; or, 2) Are arbitrarily declared to be members  by a policy implementation; or, 3) A common need for the services of the container which hosts the group. [Policy]
• Parts may choose to self-remove themselves from the group. [Policy]
• Members implement a common interface.
• Members are not aware of each other. [Policy]
• The group (as a lexical collective) is a concept different and apart from the group’s hosting context.  For example:  there is a difference between an elevator and those_who_are_on_the_elevator.  We may speak of the elevator_people as either being on the elevator or awaiting_arrival of the elevator at their floor.

Notation: An Association stereotyped as <<memberOf>>.  Association ends may be adorned with navigation arrowheads and ownership diamonds.  A link name (formed by the conjunction of two verbs, or verb phrases, separated by a slash) assists the reader in verbalizing the association from either of its ends. Serious consideration should be given to the use of an Association Class to provide information about, and methods to manage, the nature of the association.

[Paolo F Cantoni]

[size=13][SNIP][/size]
• Members implement a common interface.

The common interface may be only that related to the membership.  That is to say, If the items are arbitrarily placed in the group, then they may not have much in common.

• The group (as a lexical collective) is a concept different and apart from the crop's hosting context.  For example:  there is a difference between an elevator and those_who_are_on_the_elevator.  We may speak of the elevator_people as either being on the elevator or awaiting_arrival of the elevator at their floor.
[size=13][SNIP][/size]

Jim,
This one I'm not so sure about...
At work, we deal with groups of people, and have a number of groups:  People_waiting_at_Stop_for_Bus, Passengers_boarding_Bus, Passengers_on_Bus, Passengers_alighting_Bus, People_at_Stop_having_alighted_from_Bus, People_away_from_Stop
We need to exercise our systems but simulating People moving between these groups (collections).  The people do different things depending on which collection they are in.  For example, a Passenger_boarding_Bus will Tag-On (with their smart-card ticket) through an entry door.  Similarly, Passenger_alighting_Bus will Tag-Off through an exit door.
I'm not sure the concept you proposed works this way...
Can you comment on whether you mean the same as me or something different?

Member_Of is a Collection is it not?

Paolo

[jeshaw2]

The common interface may be only that related to the membership.  That is to say, If the items are arbitrarily placed in the group, then they may not have much in common.

I have been to many social and political gatherings that were like this.  

I'm suggesting that the binding force of the group may be outside of UML's ability to graphically model, thus making membership apparently arbitrary.  If fact, the binding force may even be outside of the problem domain and unavailable for analysis.

Member_Of is a Collection is it not?

This depends on your use of the term Collection.  If you are using Collection as a synonym, I think I would agree; but, I don't think you are using the term that way.  I perceive that you are using Collection as a Metonymy.  I find this usage confusing when abstracting the Member_Of meronymy.

I  think of Collection as a, perhaps, specalized form of a Container, which (like   Bock's assertion that on a Context Structure diagram the Class provides a context for its Parts)  provides a context within which a group exhibits behaviors.

I'm trying to keep the abstraction of Group separate from the abstraction of the Container and from the abstractions of the group's behaviors.  For example:  People, as a group, exhibit different behaviors when their Container/Context is:  A jail, an office, isOnFire=true, etc.  I'm suggesting that the abstraction features of being a Member_Of a group are different from the abstraction features of being a Part_OF (or Contained_By) a container, and also different from the features within my (not yet posted) Abstraction of the Sub_Activity_Of Meronymy.  

I'm reflecting on the possibility that all of these sub relations come together in an n-ary association with different stereotypes (or Roles?) on each leg which would then describe how membership in a group, working within a specific context, effects a subjects behavior.    Kinda allows polymorhpism abstraction with out being confined to a method's signature.  

Could it be that the group names used in your examples (e.g.; people_on_a_buss) are names of the n-ary associations, not the names of the groups?

Does this help?

[Paolo F Cantoni]

Jim,

Again, just a quick note.

Yes, I was only using Collection as a synonym, but I agree that a Collection is very specialised (weak) form of Container.

Previously we've basically said:
Every Container has an implicit Collection (those items in it).  Only some Collections exhibit Container Characteristics.

As to my example,  I was focusing on the fact that at work we need to move a specific item between the "collections".

As far as I can tell I'm not using metonymy...

Paolo

[jeshaw2]

Paolo;
I'm sorry, I need more help here.  My question was too ambiguous.

Yes, I was only using Collection as a synonym

As a synonym for which, Collection or Group?

Only some Collections exhibit Container Characteristics.

Can you expand on this, perhaps with a simple example?

I'm trying to certify that we are in agreement that the Abstraction features of the (has a)Member_Of a Group relationship are a different topic of discussion from the Abstraction features of (Is_a) Container object.

I'm thinking that a container and a group are two different entities, but that a container may contain a group at some point in time.  For example: consider a DataSet object which is the target of a database query.  The query returns a set of records (the group) having common values of shared attributes (the query criteria) and places them in the DataSet object (the container).

[Paolo F Cantoni]

As a synonym for which, Collection or Group?

Collection as a group of items.  {several things grouped together or considered as a whole}  The Collection is the whole, the items are connected to the whole by «memberOf» Associations.

I think we've now established that a Container is not a meronymy since there are no "parts" for the container whole (unless we consider the Container as a more abstract composite object - for example, bucket has bowl, handle, lid?).  Certainly, the items contained form a collection:  "Items in the bucket" - which is a whole.  It seems to me that the Collection is a peculiar whole, it can exist without any members!

By the way, I recommend using the meronymic name for the whole and non-whole,  Thus:
Composite has components (or parts), Collection has members (or items), Mass has portions, Material has substances, Activity has sub-activities  etc.  That way we can maintain precision in specification.

I'm trying to certify that we are in agreement that the Abstraction features of the (has a)Member_Of a Group relationship are a different topic of discussion from the Abstraction features of (Is_a) Container object.

OK, for me anyway, things are clearing up a bit... For the sake of the discussion, assume Collection is the term for the whole of which there are «memberOf».  An object (Is_a) Collection if it (Has_a) set of members.  It (Is_a) Container if restricts access to the contained.  If is is a Container , it also has a Collection (the items contained).

So, Collection is about grouping, Containment is about access (DOH!!! Self-evident? )

We can discuss a container's collection properties transitively...  The container holds three items is really container.collection.count=3.  Is the container Empty?

Intuitively (and by policy), an item can belong to many groups at once.  As we've previously discussed, sometimes the item knows what groups it's in , sometimes it doesn't (do you know if you have an FBI file? )

My problem is that some things that are obviously Collections may also exhibit Container characteristics...  For example a team of players...  The problem occurs when the policy is that you can only be a member of one team at a time (for example in a certain League).  

But maybe that's the solution, the object is both and the appropriate policies are applied...
A team is ALWAYS a Collection, but MAY sometimes be a Container.
A bucket is ALWAYS a Container and therefore ALWAYS has a Collection of what's in the bucket (which may be empty)

I'm thinking that a container and a group are two different entities, but that a container may contain a group at some point in time.  For example: consider a DataSet object which is the target of a database query.  The query returns a set of records (the group) having common values of shared attributes (the query criteria) and places them in the DataSet object (the container).

Following my thinking out loud  I'm not sure that the DataSet is a container, it is a Collection but if the item (a record) is still accessible then it isn't a Container.  Perhaps if the Dataset Locks the records, then it's a container?

Anyway, there some thoughts...

Paolo

[jeshaw2]

Collection as a group of items.  {several things grouped together or considered as a whole}  The Collection is the whole, the items are connected to the whole by «memberOf» Associations.

YAHOO!

I think we've now established that a Container is not a Meronymy since there are no "parts" for the container whole

You got me dancing now!

By the way, I recommend using the meronymic name for the whole and non-whole,  Thus:
Composite has components (or parts), Collection has members (or items), Mass has portions, Material has substances

I can agree with these now.

Activity has sub-activities

Provisionally accepted until I complete my thoughts on the abstraction of that sub-relation.

assume Collection is the term for the whole of which there are «memberOf».

So far, so good.

An object (Is_a) Collection if it (Has_a) set of members.

is inconsistent with

It seems to me that the Collection is a peculiar whole, it can exist without any members!

But this is easily fixed with allowances for null sets.

It (Is_a) Container if restricts access to the contained.

This is one of several services a Container may provide.  I think Containers and Containment are worthy of another concurrent thread for awhile.  And if you don't perceive a Nest to be a specialization of Container, the Nest needs a thread too.

If is is a Container , it also has a Collection (the items contained

A couple of thoughts here:
1)  Which Meronymy Stereotype would you use for the has a association?
2)  What would the cardinality at the member association end be?

My problem is that some things that are obviously Collections may also exhibit Container characteristics...  For example a team of players...  The problem occurs when the policy is that you can only be a member of one team at a time (for example in a certain League).

Ah grasshopper!   Clarification of thought is the path to understanding...  You have combined two issues to make a complex problem that may be unsolvable as a whole.

1) A member can be in more than one collection at the same time.  Different collections may be in different containers.  Ergo, members may be in more than one container at the same time.  We may need more discussion on this point to get comfy with it.  But for now, it sets up your problem.

2) You commingle the concept of a team (the collection of players) with a Container (the Organization; e.g. Boston Red Sox) that Owns the team and with the contract that exists between them(attributes of the association).  The membership association is an n-ary association that also contains a Contract declaring the 'one team membership' rule as a constraint.

The exclusive membership policy may be shown as a constraint on the memberOf association.  Can you raise the abstraction level on this?

I'm not sure that the DataSet is a container, it is a Collection but if the item (a record) is still accessible then it isn't a Container.  Perhaps if the Dataset Locks the records, then it's a container?

Forgive me, I lapsed into VB.net speak.  In that context, a Dataset holds the retrieved records disconnected from the database and provides access and navigation services to the collection of records.

But maybe that's the solution, the object is both and the appropriate policies are applied...
A team is ALWAYS a Collection, but MAY sometimes be a Container.
A bucket is ALWAYS a Container and therefore ALWAYS has a Collection of what's in the bucket (which may be empty)

Not completely sold on this; see above remarks.

[Paolo F Cantoni]

[[size=13][SNIP][/size]

OK.. We appear to be in violent agreement!

This is one of several services a Container may provide.  I think Containers and Containment are worthy of another concurrent thread for awhile.  And if you don't perceive a Nest to be a Specialization of Container, the Nest needs a thread too.

Sounds good...  I think a Nest is a specialized container.

A couple of thoughts here:
1)  Which Meronymy Stereotype would you use for the has a association?
2)  What would the cardinality at the member association end be?

One of the problems with "has" in natural language is that it doesn't always map to Has_a.  The Container contains a Collection (of items in it).  The Collection is a «collective» Attribute of the Container (as mentioned in response to your isOrdered isUnique question).  So there's no meronymy between the Container and its Collection (as far as I can see).

Ah grasshopper!   Clarification of thought is the path to understanding...  You have combined two issues to make a complex problem that may be unsolvable as a whole.

Yes, Master...
But seriously, in my experience worrying about some of these rather (to most) subtle distinctions is the key to creating a valid CIM (Computationally Independent Model).  Further, in my experience, having the right CIM is the key to creating a system that really works!

1) A member can be in more than one collection at the same time.  Different collections may be in different containers.  Ergo, members may be in more than one container at the same time.  We may need more discussion on this point to get comfy with it.  But for now, it sets up your problem.

2) You commingle the concept of a team (the collection of players) with a Container (the Organization; e.g. Boston Red Sox) that Owns the team and with the contract that exists between them(attributes of the association).  The membership association is an n-ary association that also contains a Contract declaring the 'one team membership' rule as a constraint.

The exclusive membership policy may be shown as a constraint on the memberOf association.  Can you raise the abstraction level on this?

Well, I've thought about this some more and using my 20yo son (Matthew) as an example:
He joined «memberOf» the local soccer club.  The club is «memberOf» local league.  My son has to be registered («memberOf») with the league.  He is «memberOf» the 1st team and «memberOf» the Reserves team (some Sundays he plays in both matches! - He loves his soccer!)  He is too old to play in the under-nn teams.  In all of these collections, the isUnique attribute is set.  By setting up all these relationships, the constraints thereon should fully define the degrees of freedom my son has to play in which matches

Forgive me, I lapsed into VB.net speak.  In that context, a Dataset holds the retrieved records disconnected from the database and provides access and navigation services to the collection of records.

I guess this is a context thing...

If you agree with this, I think we can put this one pretty much to bed...

Paolo

[jeshaw2]

Paolo;
Just a quick note, I'm getting ready for work...

Not sure what you meant by the "Action Tab" reference, but I did find this...

• The “Attributes” sub-section of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*. This is followed by a textual description of the purpose and meaning of the attribute. If an attribute is derived, the name will be preceded by a slash.

My thinking about multiplicity here is that a container may contain 0..* collections and still keep each collection distinct.

One of the problems with "has" in natural language is that it doesn't always map to Has_a.  The Container contains a Collection (of items in it).  The Collection is a «collective» Attribute of the Container (as mentioned in response to your isOrdered isUnique question).  So there's no meronymy between the Container and its Collection (as far as I can see).

«collective» Attribute is a new concept for me.  So is the idea of an attribute's multiplicity.  I'll think about these at work today.  Perhaps we have a pure Shared Aggregation here?

In all of these collections, the isUnique attribute is set.  By setting up all these relationships, the constraints thereon should fully define the degrees of freedom my son has to play in which matches

I thought isUnique related to this, but I didn't know how

[Paolo F Cantoni]

[size=13][SNIP][/size]

Not sure what you meant by the "Action Tab" reference, but I did find this...

Makes two of us... Don't know where your reference is.   As far as I know, I haven't used the phrase "Action Tab".

Paolo

[jeshaw2]

Class Attributes can be Collections (I stereotype them «collective»).  EA supports this (see Details Tab of Attributes Dialog)

I got the whole reference wrong.  The above quote is from the isUnique... thread.  Sorry  

[SF_lt]

I have a fealing, that sometimes you want existing collections describe with a single structure. I would differentiate logic collections/containers and physical ones. In logical case you can assign same item to difference collections/containers, but in physical world it's complicated.
Domain of interest would implicate, what constaints (policies) and logical or physical containers/collections are used.

Overall, I like idea about grouping and access - it has power
:-D  and it's not advised to read your threads before sleep  

[jeshaw2]

A good observation SR_It.  I would describe it slightly differently I think.

I'm also seeing two approaches the modeling of MemberOf, each of which are differentiated by how the whole part of the relationship is handled along with any associated container features.

In approach "A", the whole part of the association is an object with only the meronymic features and is differentiated from a second container object with the containership features.  In approach "B", one object combines the features of being both the whole part and the container.

I see value in both approaches, but would select one or the other based upon the contingencies presented by the domain.

I still have some unresolved thoughts for this thread though:
 
Under approach "A":

• It is possible for the container to contain (be associated with?) more than one group and the containment thereof can be dynamic.
  

• The fact that a group is in a specific container does not always mean that all members of the group are present in the container?  Its possible that some members may be absent? (Like I was from Sunday services today )
  

Under Approach "B"

• The container may only hold one group and the holding thereof is static.

Both approaches avoid problems present in the other.

Do we have concurrence on these, or are there other view points to consider?

Another thing to discuss in whether or not the notation should make those attributes related to membership recognizable on the diagrams as a cohesive subset , and if so, how?

And finally, one of our abstraction points is that "membership is based upon common values in a shared subset of their attributes".  Should we expand this to include "a shared subset of their behaviors"?  It would then read: "membership is based upon common values in a shared subset of their features".  

Thoughts anyone?

[SF_lt]

isn't group the same as collection? of course, group can be described as a sub-collection (subset).

Containers can contain only items, which match containment characteristics - through the inheritance, interface, policies.

In many real cases, collections are substituted by the containers, but logical container can contain several collections/groups. Everything is ok until is a need to use collections in the real world- container must support such activities.
For example: container for students, but logicaly we can differentiate all students into males and femates (gender policy) & so on

A approach is closer for me - not all students can be assigned to container - ill ones will be assigned to hospitals or drug-stores  

[jeshaw2]

SF_It;

isn't group the same as collection?

I think that we've arrived at a conclusion that the features associated with being a group are different from the features of being a container.  We've also asserted that a collection is a weak container.  Given that, the answer to your question is a matter of packaging;  which features are packaged into which objects.  They can be in separate objects or in the same object as the modeler's needs require.  

In my mind, several groups may be in one container as long as their members all implement the container's interface.