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.