RE: [mdt-sbvr.dev] Re: The kernel ofSBVRwithoutprogrammingconsiderations

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Dave,

The metamodel and the text of SBVR are not inconsistent. And you are correct
that no term, expression, concept, etc. is a fact. This is not a
contradiction. 

What are facts, which is what is expressed in the interchange documents, is
that certain terms, expressions, concepts, etc., as specified by the XML
element names in the interchange file, exist.  These are existential facts.
Interchange documents also contain instances of fact types, which are facts
that the relationship specified by the XML element name exists. The example
in 13.4 says, in part, that there is a concept "company" and that there is a
company "E-U Rent". These are facts at two different meta levels. These
facts instantiate the sbvr conceptual schema, or part of it.

The things that are said to exist are those in the interchange document that
have a xmi:id attribute. They are instances of the metaconcept identified by
the XML element name. For example, <sbvr:designation xmi:id="company"
signifier="company-t" meaning="company-c"/>. This interchange element states
three facts (in English):
  1. There is a sbvr:designation that has xmi:id="company". 
  2. The signifier of the designation is the thing that has
xmi:id="company-t", and 
  3. The meaning associated with the designation is the thing that has
xmi:id="company-c". 

xmi:id is the reference scheme for things in interchange files.

Your diagram is a model of part of the sbvr conceptual schema. The
interchange file consists of facts based on that schema. The facts and the
schema are different things. A fact model is a set of facts. The schema is
designated in the interchange file by the value of the xmlns:sbvr attribute
in the XMI element. A fact model can be a description of a schema, as is
this one, which says there is a concept designated by a particular
signifier. A conceptual schema has at least one concept; otherwise the fact
model is just a collection of ground facts, a database. The conceptual
schema is much more than just the designations and fact type forms in its
namespace. All of the definitions and necessities and possibilities are also
part of the schema. These are known as schema facts. The presumption is that
you can get the fact model of the schema to find out what these are, if you
want to verify that the provided fact model is consistent with the
conceptual schema. To interchange a fact model, only the designations and
fact type forms of the schema are needed, together with a reference to the
schema.

Where SBVR is lacking is that it does not include "thing has URI", which you
would like to use to assign URIs to your fact models. I said before that you
don't need to include a <factModel/> element in the interchange file.
However, you do need to include such an element if you want to say anything
about the fact model, such as its URI, give it a name (by conceptualizing it
as an individual concept of that name), or associate Dublin Core or other
metadata with it (all of which except for the name are outside the scope of
SBVR or MRV). It is also lacking "fact model incorporates fact model", which
allow you to compose fact models, like "import" in Java, or package import
in UML. (An instance of "fact model" is a package in UML or ecore).

Stan


> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
> Sent: Monday, June 02, 2008 6:50 PM
> To: 'SBVR developer list'
> Subject: RE: [mdt-sbvr.dev] Re: The kernel 
> ofSBVRwithoutprogrammingconsiderations 2008-05-31-2112
> 
> Stan,
> 
> When I refer to the "metamodel" I an referring to the formal 
> definitions and
> the normative CMOF model that is delivered with the SBVR 
> specification.
> Those formal definitions *should* agree with the CMOF model.
> 
> You a referring to the text in the specification.  It appears 
> that they are
> inconsistent.  In the metamodel, a term, expression, concept, 
> etc. are NOT a
> kind of "fact".  At least, not the "fact" that is defined in 
> the metamodel.
> You may refer to an XMI document as a fact model, but this is 
> different from
> the formal definition of "fact model" in the metamodel.  Look a the
> metamodel class diagram referenced in my previous email.  
> That "fact model"
> cannot include concepts, terms, or expressions.
> 
> Dave
> 
> > 
> > There appears to be a misunderstanding about what a fact 
> > model is. See SBVR 13.4. Every SBVR interchange document is a 
> > fact model, which is nothing more than a set of facts. Any 
> > set of facts is a fact model, by definition. 
> > 
> 
> > You don't have to have a <factModel/> element in the file 
> > (but you could). The file contents constitute a fact model. 
> > If you asked me to give you a fact model, I would give you a 
> > file that contains some facts. It would not need to say 
> > inside the file, "this is a fact model", but it is a fact 
> > model, by construction, and by my telling you it is to be 
> > interpreted as such. The XMI document element and reference 
> > to a conceptual schema (identified by a namespace URI) 
> > identify the file as a SBVR fact model, as in the example of 13.4.
> > 
> > Stan
> 
> 
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
>