From:
mdt-sbvr.dev-bounces@xxxxxxxxxxx [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark H Linehan
Sent: Tuesday, November 25, 2008
1:46 PM
To: SBVR developer list
Subject: RE: [mdt-sbvr.dev] 3rd
set of comments on MRV
I inserted a few comments like this, prefixed with "Mark:"
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
"Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>
"Stan
Hendryx" <stan@xxxxxxxxxxxxxxxx>
Sent by:
mdt-sbvr.dev-bounces@xxxxxxxxxxx
11/22/2008 12:41 AM
Please respond to
SBVR developer list <mdt-sbvr.dev@xxxxxxxxxxx>
|
|
To
|
"'SBVR
developer list'" <mdt-sbvr.dev@xxxxxxxxxxx>
|
cc
|
<mdt-sbvr.dev-bounces@xxxxxxxxxxx>
|
Subject
|
RE:
[mdt-sbvr.dev] 3rd set of comments on MRV
|
|
I’ve replied like this, marked
“Stan:”
From: mdt-sbvr.dev-bounces@xxxxxxxxxxx [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark H Linehan
Sent: Friday, November 21, 2008 1:47 PM
To: SBVR developer list
Cc: 'SBVR developer list'; mdt-sbvr.dev-bounces@xxxxxxxxxxx
Subject: RE: [mdt-sbvr.dev] 3rd set of comments on MRV
I added yet more, like this. I prefixed
mine with "Mark:" to make it clearer.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
"Stan Hendryx"
<stan@xxxxxxxxxxxxxxxx>
"Stan
Hendryx" <stan@xxxxxxxxxxxxxxxx>
Sent by: mdt-sbvr.dev-bounces@xxxxxxxxxxx
11/21/2008 12:56 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,
I’ve added some more in this pen.
Stan
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.
Mark: I am specifically interested in the
AtomicFormulation part of LFSV in order to enable Actualities such as
"driver Bill has car A". I have been experimenting with such modeling
in order to understand the characteristics of the design when applied to
individual concepts and instances.
Stan: Right. I understand.
Sentences formulated as a single atomic formulation with no logical operations
or quantifiers is an important subset of LFSV. These can be directly related to
a particular row and column in a relational table, e.g. Driver Car
Bill A
Stan B
…
The values are literals that satisfy a reference scheme for the concept at the
head of the column, i.e. are identifiers.
Mark: yes, but your
reference to a "relational table" is a little confusing. It seems to
me that an AtomicFormulation can avoid using quantified variables only be
referencing IndividualConstants and/or Expressions. As soon as you want an
AtomicFormulation to reference instances in a relational table, you must use
quantified variables for the references.
Stan: Each fact type instance is
represented by one row in a relational table. Each atomic formulation of a fact
type of arity n is represented by some particular n columns in the table. The
primary key of the table consists of columns that map to the roles of a
particular reference scheme for the concept whose extension is given by the
table. (Reference schemes are as important in SBVR modeling as keys are in DB
modeling.) In a relational table, several fact type instances having the same
key subject may constitute a row. You are correct that the roles of an atomic
formulation are always bound to an individual concept or an _expression_ (usually
text or a number). Your example, “Driver Bill has age 35,” fits
this case. Quantified expressions relate to the whole table, not just one row. For
example, ‘each driver is of age’ is a constraint on the whole
Driver table.
* 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.
Mark: yes, a "driver" is an
object type. I am "an IndividualConcept of
"Driver"". I don't bother
with the clause 11 "name" concept but instead have a fact type
"driver has name" to identify a model-specific "name"
concept associated with the "driver" concept.
Stan: This highlights a
difference between the use of an individual concept of a general concept and a
reference scheme for the general concept. If {name} is a reference scheme for
“driver”, then existential facts of different drivers can be
instantiated without the need to individually conceptualize each:
Driver Table
name:
Bill
Mark
Stan
A thing only needs to be
individually conceptualized if it needs to be distinguished and is in a
conceptual schema. Then, it can play a role in fact types, like any other
concept. For example, EU-Rent might include the individual concept designated
by “EU-Rent” in its conceptual schema as a distinguished thing in
order to formulate fact types that are unique to it, or refer to it by its
designation in the schema without having to have an associated
“name” fact type role.
Mark: yes. But I am
trying to do something else, and the use of the role name "name" is
confusing. Try a different example, such as "Driver has Title" where
"Title" has "General Concept: String". Clearly, I can have
an AtomicFormulation for "Driver Bill has Title 'chauffeur'", where
"Bill" is an IndividualConcept of "Driver".
Stan: Agree.
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.”
Mark: This is not very satisfactory. (a)
I don't think I should have to extend my model to say that "age is the duration since birth" in order to express the number, if I don't find it valuable to me;
(b) if I did this, it still doesn't answer how I would bind the number
"35" to the number part of the quantity value.
Stan: In any fact model, what
kind of thing “age” is depends on the conceptual schema of the fact
model. If you defined “age” as a specialization of
“number,” then you can refer to an age by providing an _expression_
for a number, like “35” or “XXXV”. It would then
require exogenous information to determine what “35” means, absent
a measurement unit in the schema. If you were using our date-time vocabulary as
part of the conceptual schema, you would probably say that an age is a duration
since birth or creation, and use quantity values as literals.
Mark: you propose an
AtomicFormulation based on "driver has age" (where "age"
has "General Concept: number") that binds "Bill" (an
IndividualConcept of "Driver") and "35" or
"XXXV". But SBVR has nothing that indicates how to interpret such an
_expression_. For example, is "XXXV" really legitimate?
Stan: If the _expression_ “XXXV”
were in the vocabulary as a synonym for “35”, it would be
legitimate.
Mark: How about we assume that a number
such as "35" is an IndividualConstant of type Number, with its name
set to the corresponding numeric value? This is justified by this sentence at
the top of page 90 in the spec: "Trivially, each fact model includes
existential facts to declare the existence of generic constants such as
numbers, ...."
Stan: No need to introduce
IndividualConstant. SBVR effectively does this by providing for a value
attribute in the XML for “number”. See SBVR 13.2.7 Data Values,
p.187.
Mark: The example in
13.3 uses a number value only for the numeric part of "... at least 3
officers." The main part of the SBVR specification does not sanction
binding a number as an _expression_.
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.
Mark: ok. Then I suppose that you specify
that "Bill is not of age" by applying a "logical not" operation
to the AtomicFormulation. Is that right?
Stan: Yes.
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.
Mark: EMF has a way to express that a
value is not known: the set(), unset(), and isSet() methods.
Stan: Good! We should use these
methods. There would be different rules if a concept is closed in a particular
conceptual schema, than if it is not closed (the default in SBVR).
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.
Mark: I think that some more development
of the MRV model is needed to "stick with what SBVR does".
Stan: It sounds like it.
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?
Mark: MDT-SBVR's version of MRV has both
FactModel and ConceptualSchema. What's needed is guidance on how these relate
to "Packages" and "namespaces". I disagree that "Namespaces are well defined in relation
to conceptual schemas" -- I can't find
anything in the spec that addresses that relationship. In any case, the
fundamental problem is that clause 8 doesn't make clear what concept is the
outer "container" for all the other clause 8 concepts. MDT-SBVR MRV
has invented "Package" for that purpose, but that's a hack.
Stan: SBVR Clause 2.3 makes it
clear that “fact model” is the outer logical container, since, as
it says, “An exchange document that conforms to this specification (an
“SBVR exchange document”) shall be an XML document [file] that
represents a ‘fact model’ as defined in subclause 8.5. The fact
model shall be based on the conceptual schema specified in subclause 13.5 - the
“SBVR model of SBVR.”” As for the relationship between
namespaces and conceptual schemas, these fact types come into play: designation
is in namespace; fact type form is in namespace; concept has designation; fact type has fact type form; “fact
type” specializes
“concept”; conceptual schema
includes concept; conceptual schema includes
fact [so-called “schema fact”]; fact model is based on conceptual schema; fact model includes fact [so-called “ground
fact”]. The concepts introduced by a conceptual schema are represented as
instances of the concept “concept” or one of its specializations
(the concept types). Each such instantiation is a fact in a interchange
document (fact model). Thus it is seen that a conceptual schema is a fact model
based on SBVR (or some chain of conceptual schemas that terminates in SBVR) and
includes facts that instantiate “concept” plus other facts,
“schema facts”, that stipulate the necessities, possibilities,
permissions, and obligations of the domain modeled by the conceptual schema,
i.e. the business rules of the conceptual schema. Any fact model that
instantiates “concept” and is ultimately based on SBVR can be used
as a conceptual schema.
Note that different conceptual
schemas might have the same concepts but different schema facts, making their
behavior quite different. This is where business rules come in in a very
significant way. It is often desirable to split a conceptual schema into at
least two parts, the concepts and the schema facts. Some of the schema facts
might be dynamic, particularly the obligations and permissions (deontic rules),
with frequent rule changes possible. Of course, changing a rule might
invalidate a lot of data, requiring potentially massive data updates to bring a
fact model (database) based on one version of the schema facts into consistency
with the new version of the schema facts (just ask any DBA!).
Mark: This doesn't help
much. Right now, the MRV model has a class called "Package" that is
used as the container for everything in the model. Perhaps this should be
"FactModel", since that is apparently supposed to be the outer
element of an XML interchange file. (But notice that clause 13.5 doesn't have a
"<FactModel>" XML element.) Or perhaps we should be using
"ConceptualSchema" since facts about the existence of concepts
apparently belong to conceptual schemas. I guess we could have a fact about a
conceptual schema inside a fact model (??) Similarly, I guess we could have a
fact about a namespace inside a fact model (??) The point is that different
tool developers will guess differently if given no guidance.
Stan: Yes, I think the outer
container should be “FactModel”. A possible mapping to ECore is
that an EPackage is an instance of “fact model”. With the EMF
Extension approach, there would be a subclass of EClass called “FactModel”,
and each instance of that class is an EPackage. Is this possible? Maybe by
having FactModel inherit from EPackage as well as EClass. Clause 13.5 doesn’t
explicitly have a “<factModel>”, but it does implicitly. Check
out the opening sentence of 13.5, “The MOF-based SBVR model of SBVR
represents facts…” Each XML element in an interchange document
represents an atomic fact, either existential or associative. So, as it says in
2.3, each interchange model is a set of facts, which is what a fact model is. A
fact model can be a fragment of a larger fact model, and still be a fact model.
The declaration of the sbvr namespace prefix in the XMI element is nearly tantamount
to an instantiation of the fact type “fact model is based on conceptual schema”,
where “fact model” is implicitly “this XMI element” and
the conceptual schema is identified by the URI “xmlns:sbvr=http://www.omg.org/spec/SBVR/20070901/SBVR.xml”.
(See 13.4, p.190.) However, this xmlns declaration is an accommodation to how
XML works, and is not quite the whole picture. The URI refers to the SBVR
metamodel, which does not include (at this juncture) the necessities and
definitions, just the namespace designations and the type hierarchy facts from
the definitions. That is all you need to interchange the model. What is needed
to tell the recipient (or the sender) how to validate the model, or produce
their own model, is the conceptual schema, which contains the schema facts
(rules, necessities) as well as the concepts. We need to be able to assign URIs
to fact models and individually conceptualize them with designations, too, in
some cases. Then we can keep fact models/conceptual schemas in repositories and
refer to them and share them and control them. This is permitted by the spec
(since it’s open world), though not explicitly present. Any model can
certainly include the fact type “fact model has URI”, or, better, “thing has URI” and then proceed to use
URIs for great flexibility, much as EMF does.
The concept “conceptual
schema” is, in fact, a role of a fact model, although this is not said in
the spec. When you create a conceptual schema, you create it as a fact model
based on, typically, the SBVR conceptual schema. It doesn’t become a
conceptual schema until it is used as such as the basis for another fact model.
Any fact model that includes an existential fact of some kind of concept can be
used as a conceptual schema. A fact model without such conceptual facts is
basically a database whose schema is the conceptual schema of the fact model. (Actually,
a snapshot of a database. Each insert, update, or delete creates, in theory, a
different fact model.) You are quite correct about developers needing guidance
on this. We can have facts about namespaces in a fact model/conceptual schema. By
using the SBVR concept “namespace” in Clause 8 we can map to a
xmlns. We should avoid the SBVR “vocabulary” concept, since it is
not really needed for MRV, and is only defined in Clause 11, and work with “namespace.”
We should work out a practical packaging scheme that is consistent with the
spec, even though perhaps not illustrated in it.
* 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_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev