Modeling A Contingent Hyponymy

[jeshaw2]

In the context of modeling Class Inclusion using a hyponymy (aka. Is_A relationship), it has been recommended that hyponymy should only refer to core relationships.

For example:

• Cow:Animal would be a core hyponymy, but
• Cow:Food might not be, for it is contingent upon context and culture
  

What would be a Best Practice for modeling a contingent hyponymy so that MDA transformation rules could take advantage of this information?

How might such a transformation rule be written?

[Paolo F Cantoni]

In the context of modeling Class Inclusion using a hyponymy (aka. Is_A relationship), it has been recommended that hyponymy should only refer to core relationships.

For example:

• Cow:Animal would be a core hyponymy, but
• Cow:Food might not be, for it is contingent upon context and culture

What would be a Best Practice for modeling a contingent hyponymy so that MDA transformation rules could take advantage of this information?

How might such a transformation rule be written?

Jim,

From my Data Management days, we used to have both static and dynamic Generalizations.  A static Generalization corresponds to your core hyponymy.   A dynamic hyponymy is handled by asking the object at run time, what kind of an object it is - your contingent hyponymy (based upon the context of the object at query application time¹).

Consider Person.  An example of a dynamic GeneralizationSet for person is: Baby, Infant, Child, Teenager, Young Adult, Adult, Senior which are determined by the age at question, and may even overlap.  In DB terms, the Dynamic Generalization is handled by a SQL View.  Unfortunately , we don't really have the equivalent of an SQL View in OO, do we?  Typically, we can implement this via an Interface with the Properties:

IsBaby, IsInfant, etc.  or a Collection of Boolean items that are their conceptual equivalent.

HTH,
Paolo
¹Query Application Time, the time to which the query applies - which may be an Event (single timepoint) or Episode (range of timepoints.  For example, what were you two years ago?

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

From my Data Management days, we used to have both static and dynamic Generalizations.  A static Generalization corresponds to your core hyponymy.   A dynamic hyponymy is handled by asking the object at run time, what kind of an object it is - your contingent hyponymy (based upon the context of the object at query application time1).

Not quite, I think.  The hyonymy is an issue at instantiation time, not query time.  It impacts the way an object is instantiated in terms of the features inherited from the contingent base classes.

In terms of your example, I think the type names you offer (infant, young adult,...,Senior) are really state names a given instance may be in as the result of an aging behavior.  But I don't want this example to become the focus of this thread; so let's not chew this bone.

Perhaps we have another Sematic Impedance point with UML?

[sargasso]

The only thing I can think of adding is that there would have to be some consistent way of modelling the context itself.  Presumeably the implementation would be along the lines of the abstract factory pattern?  maybe working backwards from a solution of that type might give some insight?

b

[jeshaw2]

Yes, something like an object factory, or dependency injection,  is probably necessary in the PIM.  I'll leave that for the architects to diagram.

I need something simple for a business analyst to use to model the contingency in UML.  I guess the transformation from CIM to PIM must be done manually, so I'll be happy with a good modeling technique for the CIM.

[jeshaw2]

I need something simple for a business analyst to use to model the contingency in UML.  I guess the transformation from CIM to PIM must be done manually, so I'll be happy with a good modeling technique for the CIM.

I'm now thinking that a constraint on the hyponymy (generalization) relation will do the trick.  It appears on the Class diagram and its presence signals a contingent relationship.

This might work well on Meronymys also.... have to think about that

[Paolo F Cantoni]

Not quite, I think.  The hyponymy is an issue at instantiation time, not query time.  It impacts the way an object is instantiated in terms of the features inherited from the contingent base classes.

Why?  If I move collections at run time, aren't I changing my hyponym?

In terms of your example, I think the type names you offer (infant, young adult,...,Senior) are really state names a given instance may be in as the result of an ageing behavior.  But I don't want this example to become the focus of this thread; so let's not chew this bone.

There is one aspect of the example that is relevant, I think.  I specifically choose this example because many of the "states" overlap - which, I think, isn't allowed in pure state machine theory (but, as always, I stand to be corrected).  But for the sake of the argument, lets assume that assertion is true.  Therefore, these (although they look like states - aren't)  From what you're saying, although they look like subtypes, they aren't.    So...

Perhaps we have another Semantic Impedance point with UML?

Yes, I think you're right here...

I attended a talk about 7 years ago on "Classless Objects".  The speaker's thesis was that you don't need classes, objects can organise themselves into groups by means of queries on their attributes.  "Get me all the objects are people and whose age is between 18 and 25".  (the equivalent of the youngAdult view previously)  I asked him is he thought this was classifying the objects?  He agreed...  So I asked him why do you think a class is called a Class?
So much for classless objects...  The question for me is: if I can classify an object, then there has to exist a class corresponding to that classification.  Most OO languages only handle static assignment of an object to a class.  But this maybe just a technology impediment.  Conceptually, I have no problem with objects being able to behave differently depending upon their dynamic state.  In particular, coming from a Design by Contract viewpoint, the ability to define specific constraints in specific contexts I think is a very powerful one.  If I can collect all these ideas into a "dynamic" Class than great...  Now if only I could find a language to implement this in...

Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

If I move collections at run time, aren't I changing my hyponym?

I'm not sure what you mean by "move collection".

If I can collect all these ideas into a "dynamic" Class than great...  Now if only I could find a language to implement this in...

Ten years ago, I had the pleasure of using a language that allowed dynamic Class specification and instantiation.   I could, at run-time, define two classes and then instantiate an object using multiple interitance.  It was specific to the Artifical Intelligence package I was using at the time.  Wish Java could do that.