Stan, thanks for your comments. I added my
own in this pen.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
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?
MDT-SBVR can focus on MRV and
get it to work to interchange fact models and conceptual schemas with concepts,
definitions, namespaces, etc., without having to involve LFSV. We can also do
VDBV then VDBR after MRV without having to do LFSV. LFSV can be done any time
after MRV. SBVR is last of all. See SBVR Fig. 2.1, p.4. This is a logical
roadmap for MDT-SBVR, with usable milestones at each compliance point. In any
case, I think we should get MRV to work before tackling any of the other SBVR vocabularies.
* 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.
I retract the above sentence.
It is false. I’m not sure what I was thinking when I wrote it! A variable
can range over any kind of concept, including a fact type. In SBVR, integers
have values that designate them; see 13.2.7, p.187. Similarly with text. Numbers
other than integers are not defined in SBVR; they need to be in a model. For
example, real numbers, rational numbers, complex numbers. ISO 6093 Number Namespace
gives designations for real 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.
I would think that “driver”
is an object type, not an individual concept, and that “Bill” designates
an individual concept that specializes “driver.” You seem to do
this in the paragraph below.
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.
However, there can be a
variable that ranges over “age,” where an age is the duration since
birth, with any fractional year of the duration truncated. A literal value of “duration”
is a quantity value, consisting of a number and a measurement unit, as “Bill
has age 35 years.”
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.
You assert that Bill is of
age by binding the individual concept designated by “Bill” to the
role of the characteristic designated by “is of age.” This action
instantiates the fact type. The instance is a fact. There is no need to deal
with the truth value explicitly. The truth value “true” is implicit
in the fact. This example highlights a compromise that is made when mapping
unary fact types to UML, needed because UML does not support unary
associations. The preferred mapping of a unary fact type, or characteristic, to
UML is as a Boolean attribute. However, the semantics are not exactly the same,
because SBVR is open world and UML is closed world. In SBVR, failure to assert
a fact does not mean that the fact is false; it means it is unknown whether the
fact is true or false. (SBVR can “close” particular concepts, and “internally
close” particular fact types as needed.) To handle this in UML and EMF,
the mapped Boolean attribute should be allowed to be null (unless the SBVR
concept is closed), representing “unknown,” and not be required to
be either true or false. The SBVR XML either includes the characteristic, its
negation, or neither. There is no need to use Boolean values in SBVR. See SBVR
13.2.3, p.184. See also 10.1.1.3, p.91ff.
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.
You don’t have to. Sorry
for the confusion.
* 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.
I agree.
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.
Yes. Better to avoid the use
of XPATH references, and stick with what SBVR does.
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.
Right.
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 think MDT-SVR should not ignore
“fact model” or “conceptual schema.” To conform to
SBVR, MDT-SBVR must recognize “fact model” and “conceptual
schema.” See SBVR 2.3, p.5. See also 10.1.1.2, p.86ff. A basic, usable,
packaging arrangement is thus included in SBVR. Namespaces are well defined in
relation to conceptual schemas. We don’t need to wait on resolving issues
with “vocabulary” to use “fact model” or “conceptual
schema”. Since every SBVR interchange file contains a fact model, “fact
model” is often implicit. However, “fact model” needs to be
used explicitly in order to specify meta data about a fact model, such as the Dublin Core meta data
elements. “Conceptual schema” is needed to express closure
conditions on concepts in conceptual schemas, as mentioned above, and to refer
to a conceptual schema in a fact model. It is clear that a fact model consists
of a set of (ground) facts and a conceptual schema. A conceptual schema
consists of a set of concepts (whose designations are in namespaces) and a set
of (schema) facts. It should be possible to include a conceptual schema in a
fact model by reference. One thing that is missing from SBVR to do this is “fact
model has URI” and “conceptual
schema has URI.” A nuance
is that “conceptual schema” is a role of a fact model in another
fact model, via “fact model is based
on conceptual schema.” Do you see anything else that needs to
be 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.
Yes.
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev