[
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
|
Stan,
I interpolated my replies, below.
--------------------------------
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-bounces@xxxxxxxxxxx wrote on 05/27/2008 12:35:01 AM:
> 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.
I believe that there can be multiple EPackages in a single .ecore file.
> 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?
An EPackage contains two kinds of things: EClassifiers, and sub-EPackages.
I would not suggest trying to extend the content, structure, or intended
meaning of EPackages.
> 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).
I believe an EPackage is a namespace in the Java or UML sense. Each
EClassifier has a single name, and each name should be unique within an
EPackage.
I don't think an EPackage can contain instances, and am certain EPackage
has no provision for reference schemes. I expect that we will represent
these kinds of concepts with "conventional" EMF-implemented classes that we
define in our model.
> 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.
I don't believe that EPackage would be appropriate for this.
>
> 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.
I agree that sets correspond to some variant of Java Collections. We need
more analysis to understand which variant.
>
> 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.
This problem has left me puzzled (and frustrated) about what packaging
concept to use if we restrict our attention to MRV,
as when modeling MRV itself. In general, I find the packaging concepts in
SBVR (vocabulary, terminalogical dictionary, body of shared meaning, body
of shared guidance, conceptual schema, fact model, namespace, vocabulary
namespace) confusing and not well aligned with each other.
> 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.
Yes.
>
> 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.
A URI is a kind of text, and a text is a kind of expression. So a URI can
already participate in a representation of any meaning. But this doesn't
help for associating URIs with things that are not meanings, such as fact
models and vocabularies.
One argument that every thing should have the possibility of a URI is that
the general Web philosophy (per the W3C0 is to make individual things
addressable via a URI. So saying that "thing has URI" would be more
consistent with the Web philosophy.
> 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.
Prefixes are an XML namespace concept, and don't really have any business
meaning. And XML namespace prefixes are not a property of a namespace or a
URI; they are a property of a reference to a URI. For example, two
different XML files might reference the same URI using two different
prefixes.
>
>
> 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
> >
>
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
