[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [gmt-dev] evolving GMT in a fully open process that allows others to join the effort
|
Ed,
You may have concerns about the terminology of a new tool we are proposing,
this is not finalized at all.
>>GMT is coming along too late, and with insufficient momentum, to redefine
>>the established terminology.
This is totally off-track. Do not confuse a tool we are planning to be used
within the framework of GMT with GMT itself.
Regards,
Ghica van Emde Boas
Bronstee.com Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347
> -----Original Message-----
> From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
> Behalf Of Willink, Ed
> Sent: Friday, March 19, 2004 10:45 AM
> To: 'gmt-dev@xxxxxxxxxxx'
> Subject: RE: [gmt-dev] evolving GMT in a fully open process that allows
> others to join the effort
>
>
> Hi
>
> > Terminology-wise, to prevent meta modellers (users
> > who develop a
> > meta model) from unadvertently slipping into the solution space, the
> > following elements are required for meta modeling:
> >
> > (a) CONCEPT - to represent the items being modelled
> > (b) RELATIONSHIP - to represent binary relationships between concepts
> > (c) ROLE - to represent the "Role" of one Concept in relation
> > to another
> > Concept via a Relationship. Each Relationship needs to
> > provide a Role for
> > the Concept at the "source" end of the Relationship and a Role for the
> > Concept at the "target" end of the Relationship.
> > (d) CONTAINER - a grouping mechanism for Concepts and
> > Relationships (which
> > contain Role definitions)
> > (e) PROPERTY - All the elements (a) ... (d) may contain any number of
> > "atomic" Properties
>
> I don't think this has been thought through.
>
> If these terms are similar to conventional terms, then users will be well
> confused.
>
> If these terms are very different then users will be well confused unless
> a major re-exposition of the prevailing state of the art is undertaken.
>
> Modelling exists at multiple levels M0, M1, M2, M3. Introducing a new
> set of names because the M1/M2 names can confuse will require yet
> more names at M2/M3 or wherever.
>
> For instance at the next level of abstraction all the above are CONCEPTS,
> and at the same level of abstraction, a PROPERTY, CONTAINER and CONCEPT
> are all varieties of 'thing'. Perhaps PROPERTY should be an
> ATOMIC CONCEPT,
> derivation, and CONTAINER a COMPOUND CONCEPT derivation. Migration from
> atomic to non-atomic is a regular occurence as a model elaborates. This
> should not involve a major change of term. I'm not at all happy
> about the equivalence of COMPOUND CONCEPT and COMPOUND RELATIONSHIP.
>
> GMT is coming along too late, and with insufficient momentum, to redefine
> the established terminology.
>
> GMT must make the best of current practice.
>
> If more precise concepts are needed then a term such as GmtClass or
> GmtRelationship should be used wherever the more precise meaning matters.
>
> Regards
>
> Ed Willink
>
> ------------------------------------------------------------------------
> E.D.Willink, Email: mailto:EdWillink@xxxxxxx
> Thales Research and Technology (UK) Ltd, Tel: +44 118 923 8278 (direct)
> Worton Drive, or +44 118 986 8601 (ext 8278)
> Worton Grange Business Park, Fax: +44 118 923 8399
> Reading, RG2 0SB
> ENGLAND http://www.computing.surrey.ac.uk/personal/pg/E.Willink
> ------------------------------------------------------------------------
>
> _______________________________________________
> gmt-dev mailing list
> gmt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/gmt-dev
>
> --
> This message has been scanned for viruses and dangerous content
> by MoveNext MailScanner, and is believed to be clean.
>
>
