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

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Dave,

"Text" specializes "expression". The fact type that links representation to
text is "representation has expression". This corresponds to the association
you are talking about. The independent thing you refer to that is not owned
by a representation is a text. The "text" class in a tool would have an
attribute, "value:String [1]", which is a reference scheme for "text". There
is a text object for each different value. This leads to some economy,
because a given text need appear but once, and can be referred to each time
it is used. A similar situation obtains for numbers. The tool will need to
be able to find text objects whose value is a given string, if it exists.
This sounds to me like a Map, not a problem. 

The use case I have in mind for this tool is a user creating a fact model
that is based on the conceptual schema "SBVR". (The user may hold the view
that they are creating a conceptual schema, or metamodel. That's fine. From
the tool's point of view, however, they are creating a fact model.) The
relevant EMF resource is a file containing the fact model. A fact model is
made up of facts: "fact model includes fact". The "SBVR" conceptual schema
is reified in the tool as a package of Java classes. Each instance of one of
these classes represents a fact that there is a thing typified by the class.
A fact model is a container for the facts it includes. In the tool, this
containment is necessarily composite, since everything in it will go away if
the file is deleted.

If a user wishes to add a new concept to their fact model, e.g. an instance
of the SBVR concept "object type", they would do so by entering a string for
the value of the text of a designation the concept, e.g. "customer". The
user then invokes a method of the tool that will instantiate a new object
type, its designation, the text "customer", and the fact that the
designation is in a particular namespace. This last step is done by
instantiating "designation is in namespace" (which namespace the user would
have created previously, as an instance of "namespace", as part of the
context for the operation). (Note that in SBVR neither a  fact model nor a
conceptual schema is a namespace; this is unlike UML and Java packages. All
of the designations and fact type forms in a fact model can be in the same
namespace, or in attributive namespaces of a common namespace, but they
don't have to be. A given concept can have different designations in the
same or different namespaces.) These instantiations are performed together,
as one ACID transaction. There are regular patterns for such instantiations.
See SBVR 13.6.1 for descriptions of common patterns for instantiating SBVR
fact models. 

Stan

> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
> Sent: Saturday, April 12, 2008 2:34 PM
> To: 'SBVR developer list'
> Subject: RE: [mdt-sbvr.dev] SBVR-uml designation.gif
<snip>
> But the metamodel still allows for Text and an independent
> object that is not owned  by the representation, by using the 
> association 
> that is also defined by SBVR for linking Representation and Text.
> 
> I want to allow for the case you described, using association 
> links, but
> make the default case easier to manage -- for both tooling and users.
> 
> But this is NOT only to work better ith EMF.  Also think 
> about this from the
> user's perspective in tooling.  I cannot imagine a successful 
> tool where
> 10,000 text object have an independent existance, and the 
> user must search
> all text objects when creating each term or name...  Describe 
> the tooling
> use case in detail for how a user would work with text 
> objects where each is
> an independent object.