[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-sbvr.dev] A proposal for modeling Concepts andrelated aspects
|
Mark,
A .ecore corresponds to a fact model, so if there is a .ecore for each
ePackage, then an ePackage corresponds to a fact model, which is a set of
facts. A fact model whose conceptual schema includes MRV may itself be used
as a conceptual schema if it contains at least one fact that there is a
concept i.e. it contains at least one existential fact, or instantiation, of
the concept "concept".
Is it possible an ePackage could correspond to sets of different kinds of
things? If so, then it might be convenient for an ePackage to correspond to
a namespace of some kind (a set of designations or fact type forms), or to
an extension (a set of instances), or to a reference scheme (a set of roles
or characteristics that is the reference scheme of a reference scheme). It
might be convenient to make the members of any one of these sets a concept
or an instance of an individual concept. The set can be an instance of an
individual concept whose designation is the name of the ePackage that
corresponds to the set. In this way, the members are implicitly part of the
set, implicitly instantiating "thing is in set", obviating the need to
explicitly instantiate them in tools. For example, the fact types
"designation is in namespace" and "fact type form is in namespace" each
specialize "thing is in set" (by virtue of their definitions, not
explicitly). Similarly for extensions and reference schemes.
Another possibility might be to correspond sets to eLists, rather than
ePackages, except for fact model (which is the document element and must
therefore correspond to an ePackage). This might be an unconventional use of
eList in EMF.
A SBVR namespace corresponds to a XML namespace. A SBVR namespace contains
only designations or fact type forms; no facts, concepts, definitions, or
other kinds of things. A namespace is not a terminological dictionary. A
namespace can have a URI.
There is a problem with "vocabulary" in SBVR. Its definition (in VDBV) makes
a vocabulary a namespace, although the examples given in VDBV are
terminological dictionaries (a vocabulary is not a dictionary). It is odd
that "vocabulary" is in VDBV, but "vocabulary namespace" and fact types
involving it are in MRV. It appears, based on their definitions, that
"vocabulary" and "vocabulary namespace" are synonyms, or nearly so, but the
spec does not say this. "Vocabulary" could be a specialization of
"vocabulary namespace" that has the delimiting characteristic of expressing
concepts within a particular body of shared meanings. In our core model, we
should use namespaces unless it is desired to associate the namespace with a
language, in which case it is a vocabulary namespace. The designations and
fact type forms in a fact model can be in different namespaces that are in
the fact model.
Unfortunately, the only fact type involving URI in MRV is "namespace has
URI". Many other things will have URI's, including many fact models. The OMG
has assigned URIs to the five fact models that are the MOF-based SBVR Models
of SBVR (15.3), but these URIs are not part of any SBVR vocabulary (and the
models have yet to be published). We should consider adding "thing has URI"
to our schema, to make for better compatibility with EMF. It could be
suggested to the RTF to include "thig has URI" in MRV, and deprecate
"namespace has URI", which would become redundant. Similarly, with prefixes,
we could add "namespace has prefix". To stay within MRV, we could make URIs
and prefixes designations; SBVR does not include the concept "prefix", so
the prefix would be just a synonym.
Stan
> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark H Linehan
> Sent: Monday, May 26, 2008 2:09 PM
> To: SBVR developer list
> Subject: RE: [mdt-sbvr.dev] A proposal for modeling Concepts
> andrelated aspects
>
> An EPackage contains:
> - sub-EPackages. There is one top-level EPackage, and a tree of
> sub-EPackages below it.
> - EClassifiers: EClasses and EDataTypes
>
> Each EPackage has a name, a URI, and a prefix. The package
> name need not
> be unique, but the URI must be. The URI identifies the .ecore
> that models
> the EPackage. The prefix is used as the XML namespace prefix
> in files that
> store instances of EClassifiers that are in the EPackage.
>
> Each EPackage is associated with an EFactory which can be
> used to create
> EClassifiers of the EPackage.
>
> The EClassifiers apparently should have unique names within
> an EPackage,
> since there is a getEClassifier(String name)
>
> A set doesn't seem to have the same semantics.
>
> I agree that it would be best to avoid mixing the MRV
> concepts with those
> from the other SBVR vocabularies. Maybe we could map EPackage to
> "conceptual schema", but the match does not seem very good. How about
> "vocabulary namespace"?
> --------------------------------
> 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@hendryxasso
>
> c.com>
> To
> Sent by: "'SBVR developer
> list'"
> mdt-sbvr.dev-boun
> <mdt-sbvr.dev@xxxxxxxxxxx>
> ces@xxxxxxxxxxx
> cc
>
>
>
> Subject
> 05/25/2008 03:14 RE: [mdt-sbvr.dev] A
> proposal for
> AM modeling Concepts
> andrelated
> aspects
>
>
>
> Please respond to
>
> SBVR developer
>
> list
>
> <mdt-sbvr.dev@ecl
>
> ipse.org>
>
>
>
>
>
>
>
>
>
> Mark Linehan wrote:
> > I forgot to list EPackages in the following list. I think
> > the closest
> > SBVR concept to EPackage is "body of shared concepts".
>
> How about set?
> What does an ePackage contain?
> We should preferably map to the concepts in the Meaning and
> Representation
> Vocabulary.
>
> Stan
>
> > -----Original Message-----
> > From: mdt-sbvr.dev-bounces@xxxxxxxxxxx
> > [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark
> H Linehan
> > Sent: Saturday, May 24, 2008 6:37 PM
> > To: mdt-sbvr.dev@xxxxxxxxxxx
> > Subject: Fw: [mdt-sbvr.dev] A proposal for modeling Concepts
> > andrelated aspects
> >
> >
> > I forgot to list EPackages in the following list. I think
> > the closest
> > SBVR concept to EPackage is "body of shared concepts". An
> > EPackage does
> > not contain individual concepts or rules, so is neither a
> "conceptual
> > schema" nor a "body of shared meanings".
> > --------------------------------
> > Mark H. Linehan
> > STSM, Model Driven Business Transformation
> > IBM Research
> >
> > phone: (914) 945-1038 or IBM tieline 862-1038
> > internet: mlinehan@xxxxxxxxxx
> > ----- Forwarded by Mark H Linehan/Watson/IBM on 05/24/2008
> > 09:22 PM -----
> >
> >
> > Mark H
> >
> > Linehan/Watson/IB
> >
> > M
> > To
> > SBVR developer list
> >
> > 05/23/2008 08:52
> > <mdt-sbvr.dev@xxxxxxxxxxx>
> > AM
> > cc
> >
> >
> >
> > Subject
> > RE: [mdt-sbvr.dev] A
> > proposal for
> > modeling Concepts and
> > related
> > aspects(Document link:
> > Mark H.
> > Linehan)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dave,
> >
> > We definitely need to do some experiments to understand the
> > ramifications
> > of the approach that I proposed. I have a summer intern
> > working with me
> > for the next few months, and I will work with him to figure
> > out the answers
> > to your questions and other questions.
> >
> > I am proposing dynamically generating the following aspects
> > of SBVR using
> > EClass:
> >
> > object types of type text or quantity as EAttributes of
> > type ESTRING
> > or EINT
> >
> > characteristics -- as EAttribute of type EBOOLEAN
> >
> > other object types -- as EClass
> >
> > binary fact types -- as EReference or EList
> >
> > I also want to look into implementing n-ary fact types and
> > objectifications
> > as extensions of EReference / EList because that would fit
> > better with the
> > above. I propose that all other SBVR concepts would be
> > implemented in the
> > "conventional" way.
> >
> > The EMF book (2nd edition, section 14.3) says that "All
> > EObjects, whether
> > generated, dynamic, or these generated/dynamic hybrids,
> > support exactly the
> > same reflective APIs. So, they can be freely mixed and used with all
> > reflection-based generic EMF utilities and frameworks, including the
> > persistence framework, change recorders, the validation
> framework, and
> > EMF.Edit. The persistence framework also supports dynamic EMF
> > directly by
> > automatically demand-loading serialized models to provide
> > needed dynamic
> > implementations for arbitrary instances. "
> >
> > The text above is not clear (to me, at least) about whether "all
> > reflection-based generic EMF utilities and frameworks" work
> > at both the
> > modeling level and the instance level. Since I am proposing
> > to represent
> > an SBVR vocabulary with a combination of dynamically-generated and
> > statically-generated EMF components, and the vocabulary needs both
> > model-level and instance-level elements, I definitely need to
> > clarify these
> > questions. Part of that can be figuring out whether one
> can export a
> > regular .ecore model file for dynamically-generated EMF components.
> >
> > - --------------------------------
> > Mark H. Linehan
> > STSM, Model Driven Business Transformation
> > IBM Research
> >
> > phone: (914) 945-1038 or IBM tieline 862-1038
> > internet: mlinehan@xxxxxxxxxx
> >
> > _______________________________________________
> > 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
>
