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.
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
To all,
If body of shared knowledge (= synonym for body of shared meanings = synonym for conceptual schema) is selected as top-level container, then with the availability of the fact type (in 11.1.1.2) "body of shared knowledge1 contains body of shared knowledge2",
there is no need to have "fact model incorporates fact model."
The fact type
"body of shared knowledge1 contains body of shared knowledge2",
gives in my opinion enough organizing power.
Regards
Sjir
From: Stan Hendryx [mailto:stan@xxxxxxxxxxxxxxxx]
Sent: Sat 5/31/2008 8:00 AM
To: date-time@xxxxxxx
Subject: RE: Scenarios
Regarding extensions -- I prefer an approach in which fact models (including
conceptual schemas) are composed of other fact models. By factoring our
metamodel into smaller reusable fact model packages, we and users can use
them to build calendars and other schemas from these components. For
instance, start off with an abstract "year" schema having an abstract origin
with months, weeks, and days of indeterminate durations. This can be
elaborated into many other calendar concepts, including the Gregorian. A
corporate fiscal calenadar could be further specified by specifying the
months and anchoring it to the Gregorian. Similarly with time schemas, which
can be composed with calendar schemas, like UTC.
One problem -- SBVR does not support composing fact models. (It has
namespace incorporates namespace.) We would need to add "fact model
incorporates fact model". The semantics of "incorporates" is similar to UML
package merge. I don't know how EMF would handle "incorporates".
Stan
> -----Original Message-----
> From: Mark H Linehan [mailto:mlinehan@xxxxxxxxxx]
> Sent: Friday, May 30, 2008 1:23 PM
> To: date-time@xxxxxxx
> Subject: Re: Scenarios
>
> Evan -- I misunderstood your original message.
>
> I think the answer to your general question "do we want to
> support user
> extensions" of our model is something like "it depends". If
> we can forsee
> a specific feature that (a) doesn't extend our scope much
> beyond our focus,
> and (b) somehow enables such extensions, then I'm generally
> in favor. In
> the case of "user calendars", I don't know (yet) what we
> would need to do
> to support such calendars.
>
> Like many other things, this is a tradeoff and there is no
> pat answer. I
> think we have to look into the details of what this would take.
>
> Having said that, "user calendars" certainly sound like they
> could be in
> scope for us.
> --------------------------------
> Mark H. Linehan
> STSM, Model Driven Business Transformation
> IBM Research
>
> phone: (914) 945-1038 or IBM tieline 862-1038
> internet: mlinehan@xxxxxxxxxx
>
>
>
>
> Evan Wallace
>
> <ewallace@xxxxxxx
>
> t.gov>
> To
> Mark H
> Linehan/Watson/IBM@IBMUS
> 05/30/2008 02:54
> cc
> PM date-time@xxxxxxx
>
>
> Subject
> Re: Scenarios
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Mark,
>
> I said that I liked the OMG scenario. I was not suggesting
> any changes
> to it.
>
> The scenarios don't just drive our thinking, they really set
> a target for
> what we produce. Presumably we will include material in our
> submission
> which
> will demonstrate how the proposal supports the scenarios. So one
> question to ask
> ourselves is: Do our scenarios exercise all the capabilities
> that we expect
> the submission to support? One capability that we *may* want
> to support
> is user
> extension. By extension, I mean allowing a user to create new model
> elements
> (not just instances) from our model. If we plan to support user
> extension (and I
> think we do), then we also need to think about the kind of extensions
> that we want
> to support. The separate scenario that I was offering would exercise
> the extension
> of our models to create user defined calendars. It would have very
> little overlap
> with the OMG scenario, but some overlap with the Academic Calendar
> scenario.
> However, it would be more business oriented and primarily
> explore extension
> capabilities. It would also be quite simple. I almost completely
> described it in
> four sentences in my previous email. The key question is: Do
> we want our
> submission to support user defined calendars?
>
> -Evan
>
> Mark Linehan wrote:
> > Evan, I'm not quite sure what you're looking for:
> >
> > Regarding defining a business or accounting calendar -- I think the
> > scenario already defines both individual dates and a repeating event
> (phone
> > calls). What additional concepts would a "calendar" add?
> >
> > Regarding reuse/extending the vocabulary -- I deliberately
> included the
> > statement about the "OMG Ottawa" meeting and then reused that when
> defining
> > the date of our face-to-face meeting. Are there other
> reuse cases that
> are
> > sufficiently different to be worth addressing in the scenario?
> >
> > I'm trying to find a balance between a scenario that is
> sufficiently rich
> > to really drive our thinking, and one that is too large or
> complex to be
> > comprehendable.
> > --------------------------------
> > Mark H. Linehan
> > STSM, Model Driven Business Transformation
> > IBM Research
>
>
>
>
>
>
>
