[
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
|
I've fallen behind in reviewing this thread...
It should not be necessary (or desirable) to map SBVR metamodel concepts to
Ecore EPackage. The EPackage is used for modules within the metamodel
definition, e.g. an EPackage for MRV or VDBV. An EPackage contains a set of
EClass definitions, e.g. Concept and FactType within the MRV EPackage.
It may help to look at other EMF metamodel definitions. For example, check
out from CVS the org.eclipse.eodm plugin. Similar to SBVR, there are
modules (like the SBVR compliance points) for RDF, RDFS, and OWL. You do
not need to think about mapping these to EPackages; this is part of the
Ecore generator when you define each of these three as a separate UML
packages that are exported to Ecore.
In the OWL metamodel, an OWLOntology is just an EClass like everything else.
In the UML metamodel, Package and Model are just ordinary Eclasses whose
content is defined by composition associations in the metamodel.
> -----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 3: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
>
>
