RE: [mdt-sbvr.dev] SBVR-uml designation.gif

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Mark Linehan wrote:
> Semantically, it is quite
> clear that a representation owns neither the corresponding meaning nor the
> corresponding expression. 

This is correct from the perspective of SBVR and semantics. There are two
implied fact types associated with an objectification. Each of them
demonstrates the designation "involves": "representation involves
expression" and "representation involves meaning." This reflects that fact
that "expression" and "meaning" are roles of the actuality that is the fact
that is the representation. It is necessary that for each actuality, some
thing is involved in each role of the actuality (based on the fact type
"state of affairs involves thing in role" and an actuality being a state of
affairs that is actual, as opposed to hypothetical or merely possible, in
which case some roles may not involve things).

The idea of composite "ownership" spoken of above is foreign to MRV,
although a concept can be designated as "composite" in VDBV, as Mark pointed
out earlier. However, ownership and navigation are important tool issues.
The question is, do we want the tool to delete by default the meaning or the
expression when we delete a representation that involves these. I think the
answer is complicated. We might want to count references to the meaning and
to the expression, and delete either of them automatically if and only if
this is the last reference, like garbage collection. To do this, we might
want every object to monitor all of its references, and when they all become
null, self destruct. 

The fact model containment structure needs to make it possible to navigate
to any object in the fact model from at least the fact model itself. The
fact model is the containment root. The fact model corresponds to a file to
which it is serialized. The fact model is connected to each object in it.
Any object not connected to some other object in a fact model can go away
and no one would notice. Java does this for us, yes? A text object may only
have references to the representations in which it is involved, so when its
last representation is deleted, the text is also deleted. Text is clearly
shareable with multiple representations; you don't need multiple copies of
"has" or "1" around; they are just expressions and mean whatever the model
chooses to have them represent.

The EMF genmodel generator has its own notion of when to create child objecs
in the generated UI, to facilitate navigation and model building. It is
supposed to create a child for each composition, but I've seen strange
behavior in this logic when some compositions are skipped, and am not sure
just how it works. I understand we can edit the generated providers to get
around this, but I'm wondering if there is a way to tune the generator to
our needs? 

Stan


> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark H Linehan
> Sent: Wednesday, April 23, 2008 7:19 PM
> To: mdt-sbvr.dev@xxxxxxxxxxx
> Subject: RE: [mdt-sbvr.dev] SBVR-uml designation.gif 
> 
> 
> I agree with Stan's observation on April 12 that an SBVR 
> "representation"
> is an association class,  I believe it doesn't show up that 
> way in the CMOF
> file because CMOF doesn't support association classes.  But 
> Figure 8.4 in
> the SBVR specification makes it quite clear that 
> "representation" is an
> association class.
> 
> Since EMF doesn't support association classes, we are still left with
> modeling "representation" as a class in EMF.  Semantically, 
> it is quite
> clear that a representation owns neither the corresponding 
> meaning nor the
> corresponding expression.
> --------------------------------
> Mark H. Linehan
> STSM, Model Driven Business Transformation
> IBM Research
> 
> phone: (914) 945-1038 or IBM tieline 862-1038
> internet: mlinehan@xxxxxxxxxx
> 
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
>