Re: [mdt-sbvr.dev] Draft of UML model for tooling metamodel

[Mark H Linehan <mlinehan@xxxxxxxxxx>]

Specific omments on the initial SBVR vocabulary that Dave posted on May 2:

* SBVR.dl2 has classes "Package" and  "Model" that don't appear in the SBVR
specification.  Why do we need these?
* SBVR-LFSV.dl2: the association between ClosedSemanticFormulation and
Meaning has a name "formulates" on the "Meaning" end.  This is wrong.  The
name of the association itself should be "formulates" or "closed semantic
formulation formulates meaning".
* SBVR-MRV.dl2, About Concepts view: A FactType has a Role, not a
FactTypeRole.  (SBVR Figure 8.2 seems to have an error where it shows "fact
type role is in fact type".  There is no such fact type.)
* SBVR-MRV.dl2, Package view: Element, PackagableElement, Package are not
part of SBVR.  A ConceptualSchema does not own Representations.
* SBVR-MRV.dl2, Meanings view: ConceptType is not in SBVR
* SBVR-VDBV.dl2, Symbolization view: QualifiedDesignations is not in SBVR.
Would it make sense to eliminate it and moved preferred/prohibited booleans
up to Designation itself?
* SBVR-VDBV.dl2, Vocabularies view: in most cases, association names are
used incorrectly as association end names

General comments:

* We need to decide the top-level container for SBVR.  A terminological
dictionary?  A vocabulary?  Body of shared meanings/shared concepts?  A
community?  How do these relate to conceptual schema and fact model?
* We should avoid adding new classes and associations, etc.  When we do, we
should include notes explaining what they mean.
 * Associations should be named according to the diagrams and associated
fact types, when the relationship is other than "has".  For example,
"Conceptual Schema includes Concept".

--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx