RE: [mdt-sbvr.dev] Re: The kernel of SBVR withoutprogrammingconsideratio

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Dave, Mark,

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. A fact
model only contains one kind of thing -- facts. Existential facts.
Associative facts. Generic facts. Partitive facts. Of course a fact model
can make assertions that certain namespaces, reference schemes, languages,
sets, representations, expressions, concepts, etc. exist. We don't include
things in a fact model, except expressions that represent facts. We include
assertions that certain things exist. My model might say "the concept "dog"
exists". However, there are no dogs in my model. My model may say "There is
a dog named "Samantha".", but Samantha is not in the model.

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


> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Dave Carlson
> Sent: Monday, June 02, 2008 10:39 AM
> To: 'SBVR developer list'
> Subject: RE: [mdt-sbvr.dev] Re: The kernel of SBVR 
> withoutprogrammingconsiderations 2008-05-31-2112
> 
> Mark,
> 
> I had also noticed that "vocabulary namespace" (in MRV) is 
> defined in terms
> of "vocabulary" (in VDBV) and had planned to submit that to 
> the sbvr-rtf
> issues.  We should create a combined list of RTF issues for 
> submission.
> 
> The SBVR definition of "thing" states in a Note that: "Every 
> other concept
> implicitly specializes the concept 'thing'."  The SBVR 1.0 metamodel
> represents this such that every metaclass is derived from 
> "thing", either
> directly or indirectly via generalization. A top-level 
> container must be
> allowed to include any "thing".
> 
> In addition to your list below, where neither "conceptual 
> schema" or "fact
> model" may include representations and expressions, other concepts are
> excluded because they are direct specializations of "thing":
> 
> * namespace
> * reference scheme
> * language
> * set (if used to represent the extension of a concept)
> * And other concepts that are not defined within MRV (such as 
> "community").
> 
> -- Dave
> 
> > 
> > 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".
> > 
> > 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.
> 
> 
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
>