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

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Dave,

Although modeling representation as a composite of expression works better
with EMF, it has an unfortunate side effect of not allowing homonymous
expressions, since composition places representation and expression in a 1:1
relationship in the proposed model. It is possible, even common, for a given
expression to represent more than one meaning. For example, bank: (1)
financial services establishment; (2) land alongside or sloping down to a
river or lake; (3) a set or series of similar things.
Representation:expression are *:1. The proposed model also does not allow
expressions that do not represent some meaning, e.g. "farb". 

SBVR has open-world semantics. Our model should avoid adding constraints not
in the spec.

Note that in the spec, figure 8.4, representation is modeled as an
association class. The reason for this is that "representation" is the
objectification of the fact type "expression represents meaning", i.e. an
instance of "representation" is an instance of the fact type, as is the case
with an association class. This is further indicated by the definition of
representation: actuality that a given expression represents a given
meaning. An expression can exist and not represent anything. A meaning can
exist and not have a representation (this is related to blank nodes in OWL
and Skolemization). However, a representation always has exactly one
expression and represents exactly one meaning.

Regards,

Stan

 

> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
> Sent: Friday, April 11, 2008 8:54 AM
> To: 'SBVR developer list'
> Subject: [mdt-sbvr.dev] Code checked into CVS
> 
> Hello all,
> 
> I checked into CVS the first version of SBVR plugins 
> generated from CMOF
> for: model, edit, and editor.  I have begun adding background 
> and design
> documentation to the SBVR project wiki: 
> http://wiki.eclipse.org/MDT-SBVR
> 
> In particular, look at the two linked pages for metamodel issues and
> metamodel modifications.  As a starting point, I have looked 
> at a small part
> of the SBVR metamodel for concept designations (e.g. Term and Name).
> 
> The general consensus from developers I've talked to is that 
> some changes
> are required to make the SBVR metamodel more usable for tool 
> development.
> This follows an approach similar to the UML2 implementation, 
> where a .uml
> file is associated with an Eclipse UML2 URI, and there is a 
> resource handler
> that loads/saves UML models to .xmi files using the OMG 
> specification URI.  
> 
> For SBVR models, the .sbvr file extension is associated with 
> an Eclipse SBVR
> URI, and the .xmi file extension uses the OMG specification 
> URI.  I have not
> yet implemented the XMI resource load/save classes for SBVR, 
> but will work
> on that next.
> 
> Regards,
>   Dave Carlson
> 
> 
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
> 
>