| [mdt-sbvr.dev] RE: The kernel of SBVR without programming considerations 2008-06-02-1521 |
(I moved this discussion to the MDT-SBVR mailing list because I think it is
more relevant there.)
Stan and Sjir and I have been discussing how to model MRV in terms of
itself. Here's my summary of the limitations of "fact model" as a "top
level container" for MRV:
* no provision for a URI
* no ability to recursively embed a fact model within a fact model
* does not include representations or expressions
And there are a couple of related issues:
* Arguably, MRV is deficient since it does not include the concept
"vocabulary", which (a) is needed to describe MRV itself; (b) is referenced
by the definition of "vocabulary namespace"
* SBVR does not address the relationship between "conceptual schema" or
"fact model" and "body of shared meanings". [Sjir: to stay in line with a goal of SBVR to use words in the commonly accepted meaning I would like to propose to give the term bosm the meaning of the union of
ground facts
domain specific conceptual schema (which may have been composed from several other conceptual (sub) schemas)
generic conceptual schema (which may have been composed of several generic conceptual subschemas)]
If we think this list is complete, then I think we should submit a formal
"issue" to the SBVR RTF with the goal of coming to a consensus on how to
proceed.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
"Sjir Nijssen"
<sjir.nijssen@pna
-group.nl> To
"Stan Hendryx"
05/31/2008 03:13 <stan@xxxxxxxxxxxxxxxx>,
PM <date-time@xxxxxxx>
cc
Subject
The kernel of SBVR without
programming considerations
2008-05-31-2112
Stan and all others,
This is the kind of exchange that I welcome. It is the kind of discussion
that I recommend to be held before any coding arguments come on the scene.
I am reconsidering the meaning of the concept and term fact model. I looked
up in my library some of the papers that were used in the seventies in
Europe in the semantic community that at that time was involved in
developing the concepts and terminology for the conceptual schema and the
information base (set of ground facts in SBVR); one of the results was the
ISO TR9007 report, Concepts and Terminology for the Conceptual Schema and
the Indformation Base. Several official publications were also dedicated to
the results of these endeavours.
In the paper "A Framework for Advanced Mass Storage Applications" published
in the proceedings of MedInfo 1980, Tokyo, I used the following axioms:
Axiom 1: Each permitted communication between a user and an information
system can be considered to consist of a set of elementary sentence
instances.
Today we would say that elementary sentence is a synonym for elementary
fact in SBVR.
Axiom 2: Each permitted communication between a user and an information
system can be completely described by one single grammar.
Synonym: A sentence base grammar is a set of rules which completely and
exclusively prescribes all the permitted sentence base instances and all
the permitted sentence base transitions.
Today we would say: domain specific conceptual schema in SBVR is synonym
for the sentence base grammar; it is fair to say that SBVR has given a
first class seat to concept defnitions.
Axiom 3: The deepest structure of each sentence can be considered to
consist of a set of ideas about objects, and a set of bridges between
objects and lexical objects.
Today look at Clause 8 of SBVR and the similarity is clear.
Axiom 4: All grammars of the coexistence architecture (the most relevant
for our discussion here are the domain specific conceptual schema and
generic conceptual schema) can be considered as information bases.
Today we may say that the domain specific conceptual schema as well as the
generic conceptual schema may be considered as elementary sentences or
elementary facts.
Hence all three levels of SBVR
I. the ground facts
II. the domain specific conceptual schema
III. the generic conceptual schema
can be considered as sets of elementary facts.
From that point of view we could try to give the concept fact model its
proper place.
My position is that we first need clarity on the most useful kernel of SBVR
concepts and full consistency before the compliance points are discussed.
What is the sense of being compliant with something that is not fully
consistent? I would recommend to get agreement on the most relevant subset
of SBVR, a manageable core working set that makes the learning and
practical application process far more productive, without sacrificing
valuable descriptive power. Think of the Pareto principle.
Hence a generic conceptual schema needs to contain a minimum set of
concepts, fact types, fact type forms and rules to be able to communicate
meaningfully in facts.
However most people would consider discussion about the generic conceptual
schema with being able to work with domain specific conceptual schemas as
too limited or only of academic interest.
In my view most practioners would consider the triple
I ground facts
II domain specific conceptual schema
III generic conceptual schema
the most useful combination in practice.
The generic conceptual schema would be developed once and hopefully
published in a way that readers are turned on.
What practical business and organisations need most is the facility to
bring all kind of regulations and requirements in a domain specific
conceptual schema in SBVR.
The majority of these practical applications also want the ground facts.
I am of the opinion that the concept body of shared meanings is exacly the
same as a conceptual schema the way it is defined in Clause 11. I am happy
to be corrected.
Kind regards
Sjir [See further below in line]
From: Stan Hendryx [mailto:stan@xxxxxxxxxxxxxxxx]
Sent: Sat 5/31/2008 5:55 PM
To: date-time@xxxxxxx
Subject: RE: Scenarios.
Sjir,
The problems with "body of shared meanings" are two fold: it is more
specific than "fact model" in that it incorporates the characteristic of
involving a given semantic community, and it is defined in VDBV, so is not
available at the MRV compliance point. It also restricts the facts it can
contain to elements of guidance. In my view, our date/time proposal, and
all other foundational schemas, needs to be usable at all SBVR compliance
points, particularly including MRV and LFSV. A conceptual schema that
extends only MRV concepts can be used at any compliance point.
In my reading of SBVR, it is implied that a conceptual schema is a fact
model that contains at least one concept, i.e. has an existential fact that
there is some concept. Such fact models can be used as conceptual schemas
of other fact models. The implication is that being a conceptual schema is
a role of a fact model that incorporates at least one concept. Every SBVR
model is a fact model, a set of facts based on a conceptual schema, so
"fact model" is the natural top-level container. [Sjir: if we make fact
model the top-level, then we have to make clear that there exists at all
times a triple <I,II,III> and that for most, if not all such triples III is
the same, and that for many, many triples II is the same. Every addition or
removal of a ground fact instance results in a new fact model. Hence I
propose to introduce another concept like version of fact model. Fact
models that have the same II and III can have many versions. Some persons
are interested in the II, some are interested in the I at a specific point
in time. Of course this reasoning can be applied to II and III also.]
you wrote:
> If body of shared knowledge (= synonym for body of shared meanings =
synonym for conceptual schema) ...
"body of shared knowledge" is not a SBVR concept at all. [Sjir: this is not
true, in my opinion; the concept is there, the term is not. The S of SBVR
is more important than the terminology, in my opinion.]
[Sjir: I would like to extend the definition of body of shared meaning to
include I, II and III. Such a definition would be relevant in many
application areas as many bodies of shared meanings need II and I and in
order to understand II properly, also need III.]
Regards,
Stan