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.
* 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.
* 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”. Uniqueness of designations and fact type forms in
namespaces is used to identify terms, names, and fact types. 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. SBVR lacks a standard version
control policy. Perhaps this project could establish some conventions to help manage
this. 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.
* 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.