Abstraction of the Substance_Of Meronymy

[jeshaw2]

What would you consider to be a good abstraction of the Substance_of Meronymy?   This is a request for comments.

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.

Commodity / Substance
This type of relation describes the material substances from which a commodity is constructed or created, or the constitutive elements of an commodity, e.g. alcohol/wine, steel/car.

• There is a clear structural relation between the commodity and its constitutive elements (substances). [Policy}
• Commodities define the types of their substances.
• Commodities are not defined by the type of their substances.
• Substances loose their distinction when they enter the relationship.
• The substances are generally not of the same type as the commodity.
• Instances of the substances loose their distinction when they enter the relationship. [Policy]
• Destruction of the commodity destroys the instances of its substances. [Policy]
• A substance instance can only be in one commodity instance at a time.
• Once in a commodity, a substance can not be removed from the association.
• Substances may need to know which commodity they are in. [Policy]
• The multiplicity of the substances must be equal to or greater than 1.
• Any given substances may, or may not, be dereferenced through an attribute containing the referencing information. [Policy]
• A commodity may have its substances ‘wired in’ at instantiation or execution time.  For example:  under Inversion of Control (IoC), commodity s may be given their part references via constructor and/or setter methods. [Policy}
• Commodities hold exclusive ownership title to instances of their substances. [Policy]

Notation: An Association stereotyped as <<substanceOf>>.  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.

[sargasso]

• There is a clear structural relation between the commodity and its constitutive elements (substances). [Policy}
         Granted.
• Commodities define the types of their substances.
         "Foodstuff" substances are all "Ingredients", cannot be other clasifiers.
• Commodities are not defined by the type of their substances.
         "Egg" can be used in different foodstuffs.
• Substances loose their distinction when they enter the relationship.
         Not necessarily, this is a temporal relationship.  "Cement", "Gravel" "Sand" and "Water" all retain their distinction until "Concrete.Mix" event occurs.
• The substances are generally not of the same type as the commodity.
         I would have thought - necessarily - given the above.
• Instances of the substances loose their distinction when they enter the relationship. [Policy]
• Destruction of the commodity destroys the instances of its substances. [Policy]
        If distinction is lost on a commodity "mix" type of event, does this not imply destruction of the substance instances.
• A substance instance can only be in one commodity instance at a time.
        Granted.
• Once in a commodity, a substance can not be removed from the association.
        Again, temporal issues arise if the "mix" type of event is considered.
• Substances may need to know which commodity they are in. [Policy]
         No comment.
• The multiplicity of the substances must be equal to or greater than 1.
         This would preclude optional or "choice of" substances.
• Any given substances may, or may not, be dereferenced through an attribute containing the referencing information. [Policy]
         Not sure what you mean - "may, or may not                              " ?
• A commodity may have its substances ‘wired in’ at instantiation or execution time.  For example:  under Inversion of Control (IoC), commodity s may be given their part references via constructor and/or setter methods. [Policy]
         May not be policy - may be determined by context or even commodity type.
• Commodities hold exclusive ownership title to instances of their substances. [Policy]
         Once "mixed".

Notation: An Association stereotyped as <<substanceOf>>.  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.

Dare I suggest <<ingredientOf>>.  

Also, Commodity may be a "compound" or a "mixture" or a "solution" or a "suspension" or .... these have different physical properties, do they need to be considered here?

[jeshaw2]

Substances loose their distinction when they enter the relationship.
     Not necessarily, this is a temporal relationship.  "Cement", "Gravel" "Sand" and "Water" all retain their distinction until "Concrete.Mix" event occurs.

When I dump flour, water, yeast, sugar, egg, and salt into a bowl, I would hardly refer to that mess as bread, not even bread dough.  They may be in a common container, but I would refer to them as a composite in that state; they have yet to enter into the substanceOf relationship as you indicate.  In my mind as I wrote these abstractions, I held the opinion that the bread.mix and bread.bake events were subActivitiesOf the new bread() constructor.  If this were not to be the case, we get into modeling the process whereby an object of one meronymic type (composite) is morphed into an object of another type (commodity) as the product of a behavior.  Perhaps an approach to accomplish this would be:  the BreadIngredients.mix() behavior could be of type BreadDough and the BreadDough.bake() could be of type Bread.

• Once in a commodity, a substance can not be removed from the association.
    Again, temporal issues arise if the "mix" type of event is considered.

See my comments above.

• The multiplicity of the substances must be equal to or greater than 1.
     This would preclude optional or "choice of" substances.

 You are correct here and zero should be allowed.  When I first wrote this, I was thinking of intrinsic substances.  I now see that a cardinality of 1 designates a substance as intrinsic.  But, I now wonder if values greater than one should be allowed?  Since the unit of measure of a cardinality is each, using the cardinality to specify 3 cups of flour won't work.  So what about a cardinality of [0..1] and using the AssociationClass to specify the quantity of the substance?

• Any given substances may, or may not, be dereferenced through an attribute containing the referencing information. [Policy]
     Not sure what you mean - "may, or may not     " ?
• A commodity may have its substances ‘wired in’ at instantiation or execution time.  For example:  under Inversion of Control (IoC), commodity s may be given their part references via constructor and/or setter methods. [Policy]
     May not be policy - may be determined by context or even commodity type.

I wish to retract this entire statement; it is at the wrong abstraction level  (i.e.; not good CIM speak).  In spite of that, you did a good job of getting to what I was thinking.  How about:

• A commodity's recipe may vary based upon the context in which the commodity is constructed.
  
  

  Dare I suggest <<ingredientOf>>.  

  I don't have strong feelings about this, however, I do feel that substance is more generic than ingredient.  Paolo has suggested that we stay with the vocabulary of the Meronymy papers; this would then call for us to use object/material instead of component/substance.  Code generators would need us to be consistent with whatever we settle on.
  
  

  Also, Commodity may be a "compound" or a "mixture" or a "solution" or a "suspension" or .... these have different physical properties, do they need to be considered here?  

  I think they should be dealt with here.  I see these terms as being either specializations, synonyms, or hybrids.
  
  In distinguishing between a partOf and a substanceOf Meronymy, whether or not the parts maintain or loose their distinction in the association is defining.  
  
  You do raise an interesting point here.  How do we treat a catalyst in the process for forming the commodity?  Such a part enables the construction of the commodity, but does not become part of it.  The catalyst maintains its distinction...  :-/  This gets into my concept of an enabling part, similar to the concept of a vehicle needing a driver to enable it to function.  Without a driver, it is still a car, but it is not functional.  In the bread domain, the bread constructor is not functional without the catalyst of heat.

[sargasso]

If this were not to be the case, we get into modeling the process whereby an object of one meronymic type (composite) is morphed into an object of another type (commodity) as the product of a behavior.  Perhaps an approach to accomplish this would be:  the BreadIngredients.mix() behavior could be of type BreadDough and the BreadDough.bake() could be of type Bread.  

Indeed!

The example I was considering was a "pick list" type of thing. It came to mind while watching "Iron Chef"      The ingredients are picked and placed at hand for the chef to do the combining.  In this case they have been removed from the pool of available ingredients but are not yet inextricably combined in the mixture.  

Surely there are similar instances in other domains.


bruce

[sargasso]

In distinguishing between a partOf and a substanceOf Meronymy, whether or not the parts maintain or loose their distinction in the association is defining.  
 
You do raise an interesting point here.  How do we treat a catalyst in the process for forming the commodity?  Such a part enables the construction of the commodity, but does not become part of it.

Aha!  Penny dropping moment.

In the bread ingredients/mixture/dough/commodity model we yet again come to the question of temporality.  It appears that not only the instance but also the meronymy morphs (in my term mutates). A "part of" collection - the ingredients on the bench mutates to a "substance of" collection on the occurence of the .mix event.

Cataylsts OTOH, are a different kettle of fish.  Even here there are two types of instance - those that can be extricated from the mix and those that cant.  A platinum catalyst in a combustion heater supports reburning of the smoke - it remains separable after the smoke mixture has passed over it,  the yeast in the bread OTOH is consumed in the proving.  IOW, two type of catalysts, second type retains the qualities of an ingredient.

bruce

[KP]

Surely there are similar instances in other domains.

How about survey responses that aren't kept for privacy reasons but are totalled with all the other responses?

[jeshaw2]

And then there are recipes that produce not only the base commodity, but also byproducts of value.  Think of that!  Multiple wholes    Can UML handle this?  :-/ The UML 2 Superstructure says that Whole/Part associations must be binary.  I need some convincing.

I'm also thinking that, while substances loose their distinction when they enter into the relationship, they can can regain their distinction by another process; e.g.; water hydrolysis to reclaim Hydrogen and Oxygen.  I would suggest that the model needs to show constraints on access to this reclamation process.  We don't want any surprising bolts of lightening from without the relationship disturbing our compound.  But I'm not sure the commodity owns this process for as the process goes forward the commodity may be destroyed and thus damage the process before it completes.  Could this process be owned by the AssociationClass?  Or, to remain self consistent,  perhaps it is better placed as a sub-activity of the Destructor process.

I don't think substances should be allowed to self-remove themselves from the association.

And I thought this sub relation was going to be easy    

[jeshaw2]

How about survey responses that aren't kept for privacy reasons but are totalled with all the other responses?

Very creative!  Gonna have to sleep on this one.