Thanks Clifford,

Therefore, the word "Concept" has the same meaning as ORM2 ObjectType, and it
doesn't denote the same thing as SBVR "Concept" term at all. I have no problem
with this. My only observation here is that the use of the word "Concept" may
look unfamiliar to other members of the ORM Community.

For the time being, I can't see the necessity for the model element Feature.

Some ORM2 model elements, like Concept (ObjectType) and Role may be named. This
means one can use words (symbols) to make reference to them. The words belong to
vocabularies (set of symbols). An ORM model element is more a matter of meaning.
I wouldn't include one of them in a vocabulary and wouldn't use their names as
primary references either, since it's possible more than one symbol, even in the
same vocabulary, denotes the same meaning. I would also like to see the element
Model in the metamodel. I couldn't attach a file to this group. I'm sending an
email with your metamodel little changed. It opens with NORMA. Please, see the
page 'discussion'. ModelElement and ModelNamedElement were taken from NORMA Core
metamodel.

I would like to propose you first to agree on these basic terms (ex.
vocabulary), as we did with "Concept". Then we'll be able to proceed the
discussion on the rest of the metamodel.

Regards, Josué


--- In information_modeling@yahoogroups.com, Clifford Heath <clifford.heath@...>
wrote:
>
> jportalfraga wrote:
> > Regarding Data Constellation ORM Metamodel
> > http://www.dataconstellation.com/ActiveFacts/examples/ORM/Metamodel.orm
> > Does the term 'Concept' stand for SBVR Concept?
>
> To be perfectly flippant, "Concept" means exactly what the model says it
> means ;-). That is, this model *defines* its own meaning for Concept.
> It's in the nature and intent of a semantic model that a concept is
> defined *only* by the roles it plays, and by nothing else. In particular,
> the natural-language meanings for words aren't definitive. Choice of
> names is a design decision for the purpose of illustration.
>
> However, to be more particular, Concept is what ORM2 calls an ObjectType.
> That is, a ValueType or an EntityType, including the objectification of a
> FactType, but not including a non-objectified FactType.
>
> I understand this to be congruent to the SBVR definition of "Noun Concept",
> which defines a class of "things". A fact type becomes a "thing" when it's
> objectified, i.e. when it becomes an EntityType. However, SBVR considers
> all fact types to be concepts, whether or not they're objectified.
>
> Refering to SBVR Rev 1.0 page 19, you'll see that the class of concepts is
> divided into noun concept and verb concept. The latter is what ORM2 calls a
> fact type. An objectified fact type consists of a noun concept (entity type)
> that "nests" or objectifies a verb concept (fact type). I don't know whether
> SBVR separates a fact type and its objectification in this way.
>
> In ORM2, an entity type that plays a role in a fact type is designated as a
> "role player", which is a descriptive term only. In SBVR, this is designated
> as a "fact type role" which is a subcategory of "noun concept".
>
> In ActiveFacts, I take a middle line between these. A Role in a FactType is
> played by a Concept, but the readings of that fact type are built of RoleRefs
> (role references) which may contain leading and/or trailing adjectives. The
> combined "adjective/concept-name" form (referred to in some places as an
> "adjectival form") is exactly what SBVR designates a "fact type role".
> However, unlike in SBVR, the adjectival form has only local scope, that is,
> the adjectives are used only to choose between fact types having the same
> players and the same predicates; the combined adjectival form doesn't have
> global scope.
>
> For example, take the two fact types:
>
> Person has given-Name;
> Person has family-Name;
>
> The predicate in both cases is "has", and the role players are the same
> (Person and Name). The adjectives must be used to indicate which fact type
> is intended, wherever that may be uncertain. Note also that in CQL, the
> hyphen is required (but only once in a given statement, see examples below)
> and need not have a white space following (for a leading adjective) or
> leading (for a trailing adjective). Unfortunately this means that hyphenated
> words like semi-trailer cannot be concept names as in ORM2. A future version
> of CQL might relax this restriction.
>
> If the same fact type must be invoked twice in the same query, CQL provides
> two alternative methods, of which only one is currently implemented.
> Consider a query that wants to find all Persons who have both John and Richard
> as given names. The fact type "Person has given-Name" must be invoked twice in
> the same query, where the Person is the same instance but the names are
> different.
>
> The first alternative (not implemented) is to use a local adjective:
>
> Person called john and richard is where
> Person is called given-Name 'John',
> Person is called other- given Name 'Richard';
>
> This is shorthand for the full query:
>
> Person called john and richard is where
> Person is called given-Name,
> given Name = 'John',
> Person is called other- given Name,
> other given Name = 'Richard';
>
> This defines a new unary fact type played by Person, having the predicate
> "called john and richard". It does this by introducing the two role names
> "given Name" and "other given Name". However, the CQL parser cannot yet
> resolve this latter role naming, where more than two words are involved.
> You see the need for this resolution in the extended form, though it's
> also needed in the condensed form in order to identify the "given Name"
> fact type. Note that the adjectival form "other given Name" only has local
> meaning within the derivation of this unary fact type.
>
> The second alternative is to use a role name:
>
> Person called john and richard is where
> Person is called given-Name,
> given Name = 'John',
> Person is called given- Name (as otherName),
> otherName = 'Richard';
>
> In this case, there is no need to resolve a three-word identifier.
>
> A query for all Persons having both names can now be formulated as simply:
>
> Person called john and richard?
>
> I was unable to convince Terry that the adjectival forms "given Name" and
> "family Name" (or for that matter a role name) should be a unique identifier
> for that role within that vocabulary (ORM2 schema or model). So as it is,
> Name might play the same "family-Name" role in two different fact types,
> such as "Person is called family-Name" and "Family is called family-Name".
> In my view, this shouldn't be allowed. Likewise, Terry says he often uses
> a role name that exists as a name elsewhere in the model. The role name is
> used merely to derive a more useful SQL column name or for illustrative
> purposes, but in my view, that shouldn't overrule the possible confusion
> from re-using such names. The problem doesn't really exist in ORM2, but it
> does in a plain-text language like CQL.
>
> Clifford Heath, Data Constellation, http://dataconstellation.com
> Agile Information Management and Design.
>