Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mdt-sbvr.dev] 3rd set of comments on MRV

Stan, thanks for your comments. I added my own in this pen.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
Inactive hide details for "Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>"Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>


          "Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>
          Sent by: mdt-sbvr.dev-bounces@xxxxxxxxxxx

          11/20/2008 10:57 PM

          Please respond to
          SBVR developer list <mdt-sbvr.dev@xxxxxxxxxxx>

To

"'SBVR developer list'" <mdt-sbvr.dev@xxxxxxxxxxx>

cc


Subject

RE: [mdt-sbvr.dev] 3rd set of comments on MRV

Mark,

Please see comments inline below.

Stan

Mark Linehan wrote:

* Most of LFSV is missing. In particular, AtomicFormulation and RoleBinding are not implemented -- and I can't model something as simple as "Driver Bill has age 35" without those.

Right. LFSV is needed to create semantic formulations.

My question is: what is the status of this. I someone planning to finish LFSV?

* Since a Text is a kind of _expression_, which is a kind of BindableTarget, I can see how the string "Bill", instantiated as a Text, can participate in an AtomicFormulation. But I don't see how a boolean true/false value or a number can be a BindableTarget. For example "Driver Bill is of age" and "Driver Bill has age 35". I think this is a problem with the SBVR spec. Comments?

A variable can be a bindable target, and the variable can range over propositions (which are true or false) or numbers. An individual concept can be a bindable target, too. One would typically bind to the individual concept designated by “Bill” rather than the _expression_ “Bill” in an atomic formulation.

My model contains a fact type "Driver has Name". (Note that I am not using the clause 11 "name" concept, but instead a model-defined concept.) To model "IndividualConcept of Driver has name Bill", I create an IndividualConcept of "Driver" and I want to build an AtomicFormulation that binds to (1) the IndividualConcept, and (2) the Text "Bill". This is possible because SBVR clause 9.2.1 says a a BindableTarget can be a Variable, an _expression_, or an IndividualConcept.

Now consider another example, "Bill has age 35. By analogy with the previous example, I would expect to create an AtomicFormulation based on the FactType "driver has age", with bindings to the IndividualConcept "Bill" and the Number "35". But I can't do that because a Number is not a BindableTarget.

It's even worse for an example involving a boolean value such as "Bill is of age". I want to create an AtomicFormulation based on the FactType "Driver is of age". I can bind the only role of the FactType to the IndividualConcept "Bill". But what do I do about the truth value? There's no way (in SBVR) to specify a boolean value and no way to plug it into the AtomicFormulation.

Regarding the point that "A variable can be a bindable target, and the variable can range over propositions (which are true or false) or numbers." -- I'm not sure how I would create a Quantification that ranges over the value "true" or over the number "35". And I believe that I shouldn't have to do that when I want to bind a literal value in an AtomicFormulation.

* I previously commented on the use of XPATH references (rather than UUIDs) between model elements. I think it should be possible to put these individual concepts in their own XML file, separate from the model file. But separating the individual concepts from the the model itself makes it likely that one will change independently of the other. Similarly, if one SBVR vocabulary incorporates another vocabulary, it is likely that they will be kept separately and evolve independently. XPATH references between separate vocabularies will be particularly brittle.

Unfortunately, “vocabulary” is in VDBV, not MRV. Use “namespace” instead of “vocabulary” with MRV, and put different namespaces in different files. Use “namespace has URI” and “namespace1 incorporates namespace2”.

OK. The MDT-SBVR MRV model currently has "Package" as a container for everything. I've previously asked how "Package" relates to "Namespace". I would be ok with eliminating "Package" and using "Namespace" as the container.

Uniqueness of designations and fact type forms in namespaces is used to identify terms, names, and fact types.

The current MDT-SBVR MRV design appears to use XPATH references. My complaint is that those are brittle. I'd be happy to have the XML file reference things via designations and fact type forms.

If designations or fact type forms are changed in subsequent versions, references will break. To maintain upward compatibility between versions of namespaces, designations and fact type forms should not be deleted, but deprecated and replaced by other terms, if a new preferred synonym is desired. Also, definitions of a term should not be changed in a new version of a released namespace unless the new definition is logically equivalent to the old one, since the term will then refer to a different concept, with unpredictable results.

Sure, but (a) there are some changes that will not cause these types of breakages in principle, but will change XPATH references in practice. (b) during the period when vocabularies are under development, it should be possible to make such changes without technology-imposed problems.

SBVR lacks a standard version control policy. Perhaps this project could establish some conventions to help manage this.

Let's get the EMF version of the metamodel done, first.

SBVR provides fact models and conceptual schemas to separate ground facts like “Driver Bill has age 35” from the schema in separate files. Each SBVR interchange file is a fact model, including fact models that may be used as conceptual schemas. Thus “conceptual schema” is a role of a fact model in another fact model. “Fact model has URI” and “conceptual schema has URI” are not included in SBVR, so there is no SBVR standard way to uniquely identify a fact model. It would be nice to have a URI for a fact model in the standard. I think “thing has URI” should be added to the spec to provide more flexible identification and reference of model elements, particularly for managing fact model modules.

Regarding the idea of adding URI's -- I would be ok with this. I suggest raising an issue on this point.

Regarding fact models and conceptual schemas -- I don't want to touch these until their relationship with namespaces, vocabularies, and the various other packaging concepts in SBVR are worked out.

* I noticed a class "Element" in MRV that isn't used anywhere, and doesn't even have a corresponding "impl" class. I think it should be dropped.

“Element” is not defined in SBVR, but is used in the fact type “set has element”, which is a synonymous form of “thing is in set”, 8.7, p.42. See also Fig. 8.9. I think “element” should be added to SBVR, rather than dropping “set has element,” since the latter is in the vernacular of technical people.

If we do that, then the relationship between "instance" and "element" should be clarified. An instance is an element of a set that is the extension of a a concept.
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev

GIF image

GIF image

GIF image


Back to the top