Hi all,



Regarding Data Constellation ORM Metamodel

http://www.dataconstellation.com/ActiveFacts/examples/ORM/Metamodel.orm



Does the term 'Concept' stand for SBVR Concept?



Regards,

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.

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.

>

On 09/06/2009, at 5:55 AM, jportalfraga wrote:

> Therefore, the word "Concept" has the same meaning as ORM2 ObjectType



For a concept to have "the same meaning", it must play exactly the same

set of roles. Please re-read my definition of "meaning" from my previous

message. My "Concept" is not the same as in either SBVR or ORM2's

ObjectType. In ORM2, an ObjectType has exactly one name, and I'm

moving my metamodel to separate *naming* from Concept.



I *intend* "Concept" to mean something much closer to SBVR's meaning

than to ORM2's meaning, so I think that the term is correct. It does

carry

the natural English meaning as well - a "term in a vocabulary denotes a

concept" - objectified as Denotation if you wish.



The existing (Compromise) and the new (Term) model fragments are

attached as images. I've uploaded them to the Yahoo files area also:



http://tech.groups.yahoo.com/group/information_modeling/files/Clifford%20Heath%2\

7s/



The fragment I'm currently using:

The revised fragment: each Concept has one definitive Term (a Name in

a Vocabulary),

and any number of synonyms. This version has been sitting in my

project files for a

while, and I keep incorporating new features from it; but not yet these:

I tried having a single fact type objectified as "Denotation" joining

Term

and Concept, but that requires a surrogate key for Concept, and I avoid

those (see below).



> , and it doesn't denote the same thing as SBVR "Concept" term at all.



Again, I intend it to mean almost the same thing as SBVR - however as I

argued before, to treat a *role* as a concept requires objectifying an

un-named

subtype of the role player. I think this is an error - the role player

is not always

objectified in this way. Objectification only applies when a role name

applies.

See for example Director in my CompanyDirectorEmployee model. By

applying

this role name, the role player is objectified as a subtype of Person,

and *becomes*

a concept. On the other hand, the role of "Company" in the same fact

type does

not have a role name and does not represent a separate (subtype)

concept.



However, this argument has not convinced Terry - see the discussion in

the list

archives around role naming and hyphen-binding from Nov 2007. So ORM2

remains different from both CQL and SBVR in this respect. CQL takes

the middle

path, and I believe it's closest to the correct one.



Furthermore, the corrected model fragment above allows a concept to

bear a

synonym from any Vocabulary (including one in another language).

However,

this fragment does not indicate how fact type readings may be

customised in

that way, which is necessary and is explicitly allowed by SBVR. Any

fact type

may have any number of readings, including many for one reading order

(RoleSequence), but though the metamodels do not yet show a Reading as

belonging to a Vocabulary, that is intended, and won't have other

impacts.



> the use of the word "Concept" may look unfamiliar to other members

> of the ORM Community.



I intend that. It is different.



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

> Feature.



You're using the version of the Metamodel from http://dataconstellation.com

,

which is slightly out of date; the version in the

http://github.com/cjheath/activefacts

source code repository is always the most recent published version.

The recent

version has eliminated Feature. I had used it for two reasons that

don't exist in

ORM2: Aliases (synonyms), and as a place to attach "business context

notes" for

use in requirements management. I've reworked both using a different

method,

but haven't integrated the changes through my code yet; see below.



> Some ORM2 model elements, like Concept (ObjectType) and Role may be

> named.

> This means one can use words (symbols) to make reference to them.



Role names in ORM2 are not unique, and may duplicate ObjectType names.

Thus they're not useful as references. I think this is an error, but

it's an error I've

retained for now, until further discussion can resolve it. See my

revised metamodel

below however.



> The words belong to vocabularies (set of symbols).



Sets of Terms that denote Concepts, yes.



> An ORM model element is more a matter of meaning.



No. An ORM2 Object Type is a named concept. A Role name is a convenience

for column-name generation during relational mapping, and little more.



> 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.



You'll see I've already been thinking along the same lines. I'm not

entirely free

to immediately correct the error, as these diagrams are crucial parts

of the

*source code* of ActiveFacts, and require changes must be followed

through.



> I would also like to see the element Model in the metamodel.



Not my view, and your Model doesn't add any capability that doesn't

already

exist.



In my view, a Model is self-contained, whereas a Vocabulary contains

terms

that denote a set of concepts relevant within some semantic space. These

semantic spaces (defined as per SBVR being the shared concepts of a

semantic community) *overlap*, and the union is potentially infinite.

A Model

is where someone chooses a limited set of vocabularies, which creates

a closed-world around them; and this model can thus be translated to an

SQL schema.



At present, this idea of "Model" is thus an *implementation* specific

thing,

not a semantic thing. It may be that this coincides with your use of

"Model",

and we can add it; but I see it as being outside the core metamodel.



> I couldn't attach a file to this group.



I don't know why not. Any member who signs in to Yahoo and visits the

Files

page should be able to create a directory for themselves and add files:

<http://groups.yahoo.com/group/information_modeling/files>



> 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 understand why you're suggesting these things, but I don't think

they are

* well-named

* all necessary

* naturally-structured.



My model already incorporates the semantic concepts of ORM2 as

implemented

in NORMA, without any of the implementation ones. In particular:



* My comments about Model above,



* "ModelElement" exists as a place to hang the geometry rules for the

diagram

    layouts, which is an implementation thing, not a semantic thing;

and unnecessary

    in any case.



* "Name" is already used wherever NORMA can use a name (an ObjectType

or Role)



* NORMA doesn't denote object types by any "symbols" other than Names

so the

    change of terminology is unnecessary.



* Since ORM2 doesn't have any relationship between ObjectType names and

    RoleNames, the proposed ModelNamedElement supertype doesn't actually

    exist in any reality. It's as redundant as my (better-named!)

"Feature" was.



* Role Names in ORM2 don't (unfortunately) to belong to a Vocabulary.

This is

    reflected still in my metamodel, and that needs to change. A role

name should

    be a Term, even though that would disallow any ORM model that re-

uses a

    Concept's term as a role name (a good thing, in my view). That's

fixed in my

    revised metamodel, though not yet in my code.



* Your proposed "Meaning" is a dangling object having no meaning.

"Meaning"

    in a semantic model is not described in paragraphs or by an ID, but

by the *roles*

    that the concept plays; and your "Meaning" has only two roles (one

played by ID,

    and one played by ModelElement). Neither of these role really

*means* anything.



* You use a lot of "id" reference modes. I avoid them wherever a

"natural" identifier

    exists. Thus "Vocabulary" has a name, and Concept is identified by

a primary Name.



> 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.



I hope you'll see my latest proposed metamodel incorporates the

capabilities you

want. It's uploaded as "Metamodel 2009-06-09.orm" in the group files.

This file

also contains incomplete support for business context notes.



Finally; I intend "Vocabulary" to play additional roles, such as one

denoting the

natural language in which it's expressed. These aren't modelled yet,

and neither

is the details of vocabularies incorporating completely, or borrowing

from, other

vocabularies (despite the "Imports" that were in earlier models).



Clifford Heath, Data Constellation, http://dataconstellation.com

Agile Information Management and Design

What about using "GeneralConcept" instead of "Concept" for better matching with SBVR? It could also be used "FactTypeForm" instead of "Reading".

I prefer to define the has synonym- relationship at the term level.

It's possible that a term neither designates a concept nor a role.

A term might have no synonyms.

Additional textual rules must be added to enforce that a term and its synonyms must belong to at most one vocabulary and have at least one common concept designated (they share a meaning, so they are synonyms within a vocabulary).  Other case  is two terms from different vocabularies that designate the same concept.  In this case  one term is the translation of the another. I think is better to derive the fact type Term has synonym-Term, if it is useful.

model fragment 

Regards, Josue

--- In information_modeling@yahoogroups.com, Clifford Heath <clifford.heath@...> wrote:
>
> On 09/06/2009, at 5:55 AM, jportalfraga wrote:
> > Therefore, the word "Concept" has the same meaning as ORM2 ObjectType
>
> For a concept to have "the same meaning", it must play exactly the same
> set of roles. Please re-read my definition of "meaning" from my previous
> message. My "Concept" is not the same as in either SBVR or ORM2's
> ObjectType. In ORM2, an ObjectType has exactly one name, and I'm
> moving my metamodel to separate *naming* from Concept.
>
> I *intend* "Concept" to mean something much closer to SBVR's meaning
> than to ORM2's meaning, so I think that the term is correct. It does
> carry
> the natural English meaning as well - a "term in a vocabulary denotes a
> concept" - objectified as Denotation if you wish.
>
> The existing (Compromise) and the new (Term) model fragments are
> attached as images. I've uploaded them to the Yahoo files area also:
>
> http://tech.groups.yahoo.com/group/information_modeling/files/Clifford%20Heath%27s/
>
> The fragment I'm currently using:
>
>
>
>
> The revised fragment: each Concept has one definitive Term (a Name in
> a Vocabulary),
> and any number of synonyms. This version has been sitting in my
> project files for a
> while, and I keep incorporating new features from it; but not yet these:
>
>
>
>
>
>
> I tried having a single fact type objectified as "Denotation" joining
> Term
> and Concept, but that requires a surrogate key for Concept, and I avoid
> those (see below).
>
> > , and it doesn't denote the same thing as SBVR "Concept" term at all.
>
> Again, I intend it to mean almost the same thing as SBVR - however as I
> argued before, to treat a *role* as a concept requires objectifying an
> un-named
> subtype of the role player. I think this is an error - the role player
> is not always
> objectified in this way. Objectification only applies when a role name
> applies.
> See for example Director in my CompanyDirectorEmployee model. By
> applying
> this role name, the role player is objectified as a subtype of Person,
> and *becomes*
> a concept. On the other hand, the role of "Company" in the same fact
> type does
> not have a role name and does not represent a separate (subtype)
> concept.
>
> However, this argument has not convinced Terry - see the discussion in
> the list
> archives around role naming and hyphen-binding from Nov 2007. So ORM2
> remains different from both CQL and SBVR in this respect. CQL takes
> the middle
> path, and I believe it's closest to the correct one.
>
> Furthermore, the corrected model fragment above allows a concept to
> bear a
> synonym from any Vocabulary (including one in another language).
> However,
> this fragment does not indicate how fact type readings may be
> customised in
> that way, which is necessary and is explicitly allowed by SBVR. Any
> fact type
> may have any number of readings, including many for one reading order
> (RoleSequence), but though the metamodels do not yet show a Reading as
> belonging to a Vocabulary, that is intended, and won't have other
> impacts.
>
> > the use of the word "Concept" may look unfamiliar to other members
> > of the ORM Community.
>
> I intend that. It is different.
>
> > For the time being, I can't see the necessity for the model element
> > Feature.
>
> You're using the version of the Metamodel from http://dataconstellation.com
> ,
> which is slightly out of date; the version in the http://github.com/cjheath/activefacts
> source code repository is always the most recent published version.
> The recent
> version has eliminated Feature. I had used it for two reasons that
> don't exist in
> ORM2: Aliases (synonyms), and as a place to attach "business context
> notes" for
> use in requirements management. I've reworked both using a different
> method,
> but haven't integrated the changes through my code yet; see below.
>
> > Some ORM2 model elements, like Concept (ObjectType) and Role may be
> > named.
> > This means one can use words (symbols) to make reference to them.
>
> Role names in ORM2 are not unique, and may duplicate ObjectType names.
> Thus they're not useful as references. I think this is an error, but
> it's an error I've
> retained for now, until further discussion can resolve it. See my
> revised metamodel
> below however.
>
> > The words belong to vocabularies (set of symbols).
>
> Sets of Terms that denote Concepts, yes.
>
> > An ORM model element is more a matter of meaning.
>
> No. An ORM2 Object Type is a named concept. A Role name is a convenience
> for column-name generation during relational mapping, and little more.
>
> > 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.
>
> You'll see I've already been thinking along the same lines. I'm not
> entirely free
> to immediately correct the error, as these diagrams are crucial parts
> of the
> *source code* of ActiveFacts, and require changes must be followed
> through.
>
> > I would also like to see the element Model in the metamodel.
>
> Not my view, and your Model doesn't add any capability that doesn't
> already
> exist.
>
> In my view, a Model is self-contained, whereas a Vocabulary contains
> terms
> that denote a set of concepts relevant within some semantic space. These
> semantic spaces (defined as per SBVR being the shared concepts of a
> semantic community) *overlap*, and the union is potentially infinite.
> A Model
> is where someone chooses a limited set of vocabularies, which creates
> a closed-world around them; and this model can thus be translated to an
> SQL schema.
>
> At present, this idea of "Model" is thus an *implementation* specific
> thing,
> not a semantic thing. It may be that this coincides with your use of
> "Model",
> and we can add it; but I see it as being outside the core metamodel.
>
> > I couldn't attach a file to this group.
>
> I don't know why not. Any member who signs in to Yahoo and visits the
> Files
> page should be able to create a directory for themselves and add files:
> <http://groups.yahoo.com/group/information_modeling/files>
>
> > 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 understand why you're suggesting these things, but I don't think
> they are
> * well-named
> * all necessary
> * naturally-structured.
>
> My model already incorporates the semantic concepts of ORM2 as
> implemented
> in NORMA, without any of the implementation ones. In particular:
>
> * My comments about Model above,
>
> * "ModelElement" exists as a place to hang the geometry rules for the
> diagram
> layouts, which is an implementation thing, not a semantic thing;
> and unnecessary
> in any case.
>
> * "Name" is already used wherever NORMA can use a name (an ObjectType
> or Role)
>
> * NORMA doesn't denote object types by any "symbols" other than Names
> so the
> change of terminology is unnecessary.
>
> * Since ORM2 doesn't have any relationship between ObjectType names and
> RoleNames, the proposed ModelNamedElement supertype doesn't actually
> exist in any reality. It's as redundant as my (better-named!)
> "Feature" was.
>
> * Role Names in ORM2 don't (unfortunately) to belong to a Vocabulary.
> This is
> reflected still in my metamodel, and that needs to change. A role
> name should
> be a Term, even though that would disallow any ORM model that re-
> uses a
> Concept's term as a role name (a good thing, in my view). That's
> fixed in my
> revised metamodel, though not yet in my code.
>
> * Your proposed "Meaning" is a dangling object having no meaning.
> "Meaning"
> in a semantic model is not described in paragraphs or by an ID, but
> by the *roles*
> that the concept plays; and your "Meaning" has only two roles (one
> played by ID,
> and one played by ModelElement). Neither of these role really
> *means* anything.
>
> * You use a lot of "id" reference modes. I avoid them wherever a
> "natural" identifier
> exists. Thus "Vocabulary" has a name, and Concept is identified by
> a primary Name.
>
> > 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.
>
> I hope you'll see my latest proposed metamodel incorporates the
> capabilities you
> want. It's uploaded as "Metamodel 2009-06-09.orm" in the group files.
> This file
> also contains incomplete support for business context notes.
>
> Finally; I intend "Vocabulary" to play additional roles, such as one
> denoting the
> natural language in which it's expressed. These aren't modelled yet,
> and neither
> is the details of vocabularies incorporating completely, or borrowing
> from, other
> vocabularies (despite the "Imports" that were in earlier models).
>
> Clifford Heath, Data Constellation, http://dataconstellation.com
> Agile Information Management and Design
>

On 12/06/2009, at 12:12 AM, jportalfraga wrote:

> What about using "GeneralConcept" instead of "Concept" for better

> matching with SBVR?

>



I assume you're using the diagram at the start of SBVR section 8.1

(snapshot below for those who don't have it open). The definition of

"general concept" in section 11.1.2.3 is in the context of

specialization.

The diagram in section 8.1 shows that each "object type" is a general

concept in the sense that individual concepts of an object type are

specializations of that object type. It's not saying that an object type

is the same thing as a general concept. That is, the concepts "my dog"

and "your dog" are specializations of the object type "dog"; dog as an

object type is a general concept for those individual concepts.



Now to justify my use of the term "Concept" for object type, I need

to show that the other SBVR subcategories of concept aren't

necessary in my metamodel, either because they're outside my

UoD, or because they are inside but don't have sufficient overlap

with object type to justify a common superclass (general category).



Referring to Figure 8.1, there are two subcategories of SBVR's

concept, and four subcategories of noun concept. I'll deal with

noun concept first. The first subcategory is "individual concept".



My model uses "Instance" for "individual concept" (despite maybe

confusing an instance of Instance with the actuality it represents).

All Instances are regarded as just being conceptual representations

of the actualities implicitly, without the need to classify Instances as

Concepts. In other words, when I populate an Instance of "Dog", it's

apparent that the Instance is a record of some particular dog, not

the dog itself. There are no common roles between Instance and

object type, so no reason for them to share a general category.



Similarly, SBVR's "fact type role" characterises the collection of

instances (individual instances in SBVR) that play the related role

in the collection of fact instances (called Fact in my model) of that

fact type. To continue the example for the above dog, if I populate

the instances of "Dog has Colour hair" to indicate the hair colours

of a collection of dogs, the colour "brown" likely plays the fact type

role for colour, but it's unlikely that "green" does. Thus the "fact

type

role" is the category of "all colours that dog hair may be", as a

restriction on the category of all possible colours. In my metamodel,

I have no need for this category as a separate concept. That might

change if I try to create a formal semantics for fact type derivation,

but at present I don't see that happening.



The final subcategory of "noun concept", is "role". In SBVR as in

ActiveFacts, a Role is the part played by a Concept in a FactType.

As before, we need to consider the roles that a Role plays in the

metamodel (to see which are shared with NounConcept), and to do

that, I'll refer to the CQL language. In CQL, a designator of a role

may take one of three forms:



* The name of an object type (including of an objectified fact type)

* The name of an object type discriminated using new adjectives

* A role name, defined using (as <some-name>)



Any of the three forms may be used within the immediate context as

a reference to that role. However, these designations have very limited

availability as general syntactic elements *outside* that context, i.e.

having global meaning within the whole vocabulary. Consider for

example a fact type "Person attended Meeting", when invoked as

"Person (as Attendee) attended board-Meeting" as one clause in the

context of a fact type derivation:



* "Person" is used to match the fact type from readings available in the

vocabulary. Because it adds a role name (Attendee, not used in matching

the fact type in the vocabulary), any reference to this role from

elsewhere

in the derivation must use the role name. Any other use of "Person" will

invoke a different role of the object type, not to this role.



* The name "Meeting" cannot be used to refer to its role, unless also

accompanied by the adjective "board". That is, a reference elsewhere

in this derivation to "board Meeting" will be a reference to this role,

and any reference to just "Meeting" will be to the object type (i.e. a

different role of Meeting). This rule is relaxed in some contexts such

as constraint definitions where a different role cannot be introduced,

and then the adjective does not have to be used. [I don't really like

the

fact that this relaxation seems ad-hoc, but it's necessary to increase

the number of NORMA models that can be converted to CQL.]



* The name "Attendee" has limited scope within this fact type

derivation.

Normally, a role name applies to a role - which means that anywhere

that fact type may be referred to, the role name is available. This is

different from a role designation that uses an adjective, the

adjective is

part of the designation (RoleRef in my model). When a derived fact type

is defined using a reading that uses a role name, that role name

becomes globally accessible for use in invoking that derived fact type.

But here, the role name occurs within the body of the derivation, and

only has local relevance, being available for use in reference to the

role

of the fact type elsewhere invoked.



It cannot be used outside this derivation, unless it's also used within

the reading text for the derived fact type. In the current

implementation

of CQL, this enlarged scope for role names isn't implemented, due to

the discussion I had with Terry about disallowing role names from

conflicting with object type names. See the discussion we had in this

Information Modeling list around November 2007. Essentially, I see

the role name in this context as introducing Attendee as a subtype of

Person, where the relevant role that makes subtyping useful is the

fact that this Person plays the role of Attendee. This subtype then

should have a name that is in the global namespace. However, if

desired, an explicit subtype can always be created to play this role,

in CQL: "Attendee is a kind of Person; Attendee attended Meeting".



So, to finish my coverage of roles as a category of noun concept, the

ability to generalise roles as "noun concepts" isn't a sufficiently

useful

thing to do, at present.



Note that although this sounds a rather contingent or subjective way

to treat it, remember that the process of modeling is a *design*

process,

not descriptive, and the formulation of a general category is useful

in a

design only where that category encapsulates roles that all

subcategories

share. In my meta-model, there is not sufficient commonality between

the roles of instances (individual concepts), object types, and fact

type

roles, to make the generalisation useful.



I should now argue why "fact type" shouldn't be a subcategory of

"concept". To generalise "fact type" and "noun concept" as "concept"

(as SBVR does) is a useful thing in defining the set of shared ideas of

a semantic community. The semantic community shares these noun

concepts and those fact types; collectively, they share these concepts.



However I don't have a need to do that. Instead I define a vocabulary,

which designates a speech community. Each vocabulary includes

terms that designate its concepts, and readings that designate its

fact types. Thus the set of concepts and fact types of a semantic

community are the sets denoted by the terms and readings used by

users of the vocabularies of that community. There's no need to

*name* a general category that encompasses noun concepts and

fact types. If a fact type needs to play any of the roles of a noun

concept, it can be objectified as one (such as in the CQL statement

"Attendance is where Person attended Meeting").



This leaves only one of SBVR's concept sub-categories (object type),

and I so call that just "concept".



> It could also be used "FactTypeForm" instead of "Reading".

>



It could, but I prefer to use less formal language where possible,

or language that is at least more memorable to a layperson once

they've learnt it. I also prefer single words where possible, and

not create artificial aggregate terms.



In CQL, a term must contain no spaces, though there is no technical

reason why I couldn't relax this in future and have multi-word terms

as in SBVR. The implementation problem is the same one that currently

prevents me using more than a single adjective before and/or after

a term.



You'll note that although my Readings are composite objects, I don't

actually show the decomposition, as SBVR does in section 8.3.4.

Instead I use placeholders by incorporating the ordinals of each

RoleRef into the reading text encased in curly brackets as NORMA

does (e.g. "{0} has {1}").



> I prefer to define the has synonym- relationship at the term level.

>



My use of the word Synonym is incorrect, as you point out.



I wanted to have just a single fact type "Term designates Concept",

but that can't provide an identifier for Concept (even if you objectify

it as Designation and add "Designation is primary"), and I don't want

to use a surrogate identifier (ConceptId). So instead I have a primary

designation and AlternateDesignation. I've changed the readings to

show that.



Your Synonym fact type is derivable from these two. I prefer not to

include derived fact types on the diagrams though. In fact, neither

NORMA nor CQL currently handles the relational mapping correctly

if you do. Also, your constraints on Synonym were insufficient.

If instead I drop AlternateDesignation and add Synonym, several

new constraints are needed to make it work correctly. It's simpler

the way it is.



> It's possible that a term neither designates a concept nor a role.

>



I believe that would be an error - unless we define new things that

can be designated by a Term. You might want to do that of course,

but them we'd revise the model. However, to make that possible, I'll

remove the mandatory aspect and leave exclusion.



> A term might have no synonyms.

>



Yes. Or a concept might have no alternate designations, same thing.



> Additional textual rules must be added to enforce that a term and

> its synonyms must belong to at most one vocabulary

>



No - the whole idea here is to allow terms from more than one vocabulary

to designate the same concept. This is how multi-lingual and overlapping

vocabularies are defined. This is not just for translation; in some

organisations

customers might be referred to as users or as clients, by different

groups

of people.



> I think is better to derive the fact type Term has synonym-Term, if

> it is useful.

>



Yes, I agree. But I won't show the derivation on my version of the

diagram,

if you don't mind. It's hard enough to read already, without that! The

fragment

I have now is as shown below.



Clifford Heath, Data Constellation, http://dataconstellation.com

Agile Information Management and Design.

> It's not saying that an object type

> is the same thing as a general concept.



I was absolutely wrong when I tried to match "general concept" to an ORM object

type.



Actually, now I think a better approximation to the interpretation of ORM is the

concept "extension":



Page 40. extension definition: totality of objects [every thing] to which a

concept corresponds



The reason is that, in ORM, both object types and fact types are treated as

sets. However, I realize that by introducing this concept your metamodel may

change significantly.



On the other hand, the main goal of an ORM metamodel is to enforce the notation

semantics. This can be done without SBVR, as you have already proved.

Introducing explicitly the SBVR terms in the metamodel may help to mapping from

ORM to SBVR and vice versa, but it's not indispensable since the two methods are

formal. This also would contribute to the understanding of the interconnection

between the methods. Perhaps a major benefit would be to facilitate the

interoperability among the fact oriented modeling tools.



Let me ask you a question. From your perspective, what are the implications of

radically changing the metamodel for the sake of a full conformity with SBVR?





--- In information_modeling@yahoogroups.com, Clifford Heath <clifford.heath@...>

wrote:

>

> On 12/06/2009, at 12:12 AM, jportalfraga wrote:

> > What about using "GeneralConcept" instead of "Concept" for better

> > matching with SBVR?

> >

>

> I assume you're using the diagram at the start of SBVR section 8.1

> (snapshot below for those who don't have it open). The definition of

> "general concept" in section 11.1.2.3 is in the context of

> specialization.

> The diagram in section 8.1 shows that each "object type" is a general

> concept in the sense that individual concepts of an object type are

> specializations of that object type. It's not saying that an object type

> is the same thing as a general concept. That is, the concepts "my dog"

> and "your dog" are specializations of the object type "dog"; dog as an

> object type is a general concept for those individual concepts.

>

> Now to justify my use of the term "Concept" for object type, I need

> to show that the other SBVR subcategories of concept aren't

> necessary in my metamodel, either because they're outside my

> UoD, or because they are inside but don't have sufficient overlap

> with object type to justify a common superclass (general category).

>

> Referring to Figure 8.1, there are two subcategories of SBVR's

> concept, and four subcategories of noun concept. I'll deal with

> noun concept first. The first subcategory is "individual concept".

>

> My model uses "Instance" for "individual concept" (despite maybe

> confusing an instance of Instance with the actuality it represents).

> All Instances are regarded as just being conceptual representations

> of the actualities implicitly, without the need to classify Instances as

> Concepts. In other words, when I populate an Instance of "Dog", it's

> apparent that the Instance is a record of some particular dog, not

> the dog itself. There are no common roles between Instance and

> object type, so no reason for them to share a general category.

>

> Similarly, SBVR's "fact type role" characterises the collection of

> instances (individual instances in SBVR) that play the related role

> in the collection of fact instances (called Fact in my model) of that

> fact type. To continue the example for the above dog, if I populate

> the instances of "Dog has Colour hair" to indicate the hair colours

> of a collection of dogs, the colour "brown" likely plays the fact type

> role for colour, but it's unlikely that "green" does. Thus the "fact

> type

> role" is the category of "all colours that dog hair may be", as a

> restriction on the category of all possible colours. In my metamodel,

> I have no need for this category as a separate concept. That might

> change if I try to create a formal semantics for fact type derivation,

> but at present I don't see that happening.

>

> The final subcategory of "noun concept", is "role". In SBVR as in

> ActiveFacts, a Role is the part played by a Concept in a FactType.

> As before, we need to consider the roles that a Role plays in the

> metamodel (to see which are shared with NounConcept), and to do

> that, I'll refer to the CQL language. In CQL, a designator of a role

> may take one of three forms:

>

> * The name of an object type (including of an objectified fact type)

> * The name of an object type discriminated using new adjectives

> * A role name, defined using (as <some-name>)

>

> Any of the three forms may be used within the immediate context as

> a reference to that role. However, these designations have very limited

> availability as general syntactic elements *outside* that context, i.e.

> having global meaning within the whole vocabulary. Consider for

> example a fact type "Person attended Meeting", when invoked as

> "Person (as Attendee) attended board-Meeting" as one clause in the

> context of a fact type derivation:

>

> * "Person" is used to match the fact type from readings available in the

> vocabulary. Because it adds a role name (Attendee, not used in matching

> the fact type in the vocabulary), any reference to this role from

> elsewhere

> in the derivation must use the role name. Any other use of "Person" will

> invoke a different role of the object type, not to this role.

>

> * The name "Meeting" cannot be used to refer to its role, unless also

> accompanied by the adjective "board". That is, a reference elsewhere

> in this derivation to "board Meeting" will be a reference to this role,

> and any reference to just "Meeting" will be to the object type (i.e. a

> different role of Meeting). This rule is relaxed in some contexts such

> as constraint definitions where a different role cannot be introduced,

> and then the adjective does not have to be used. [I don't really like

> the

> fact that this relaxation seems ad-hoc, but it's necessary to increase

> the number of NORMA models that can be converted to CQL.]

>

> * The name "Attendee" has limited scope within this fact type

> derivation.

> Normally, a role name applies to a role - which means that anywhere

> that fact type may be referred to, the role name is available. This is

> different from a role designation that uses an adjective, the

> adjective is

> part of the designation (RoleRef in my model). When a derived fact type

> is defined using a reading that uses a role name, that role name

> becomes globally accessible for use in invoking that derived fact type.

> But here, the role name occurs within the body of the derivation, and

> only has local relevance, being available for use in reference to the

> role

> of the fact type elsewhere invoked.

>

> It cannot be used outside this derivation, unless it's also used within

> the reading text for the derived fact type. In the current

> implementation

> of CQL, this enlarged scope for role names isn't implemented, due to

> the discussion I had with Terry about disallowing role names from

> conflicting with object type names. See the discussion we had in this

> Information Modeling list around November 2007. Essentially, I see

> the role name in this context as introducing Attendee as a subtype of

> Person, where the relevant role that makes subtyping useful is the

> fact that this Person plays the role of Attendee. This subtype then

> should have a name that is in the global namespace. However, if

> desired, an explicit subtype can always be created to play this role,

> in CQL: "Attendee is a kind of Person; Attendee attended Meeting".

>

> So, to finish my coverage of roles as a category of noun concept, the

> ability to generalise roles as "noun concepts" isn't a sufficiently

> useful

> thing to do, at present.

>

> Note that although this sounds a rather contingent or subjective way

> to treat it, remember that the process of modeling is a *design*

> process,

> not descriptive, and the formulation of a general category is useful

> in a

> design only where that category encapsulates roles that all

> subcategories

> share. In my meta-model, there is not sufficient commonality between

> the roles of instances (individual concepts), object types, and fact

> type

> roles, to make the generalisation useful.

>

> I should now argue why "fact type" shouldn't be a subcategory of

> "concept". To generalise "fact type" and "noun concept" as "concept"

> (as SBVR does) is a useful thing in defining the set of shared ideas of

> a semantic community. The semantic community shares these noun

> concepts and those fact types; collectively, they share these concepts.

>

> However I don't have a need to do that. Instead I define a vocabulary,

> which designates a speech community. Each vocabulary includes

> terms that designate its concepts, and readings that designate its

> fact types. Thus the set of concepts and fact types of a semantic

> community are the sets denoted by the terms and readings used by

> users of the vocabularies of that community. There's no need to

> *name* a general category that encompasses noun concepts and

> fact types. If a fact type needs to play any of the roles of a noun

> concept, it can be objectified as one (such as in the CQL statement

> "Attendance is where Person attended Meeting").

>

> This leaves only one of SBVR's concept sub-categories (object type),

> and I so call that just "concept".

>

> > It could also be used "FactTypeForm" instead of "Reading".

> >

>

> It could, but I prefer to use less formal language where possible,

> or language that is at least more memorable to a layperson once

> they've learnt it. I also prefer single words where possible, and

> not create artificial aggregate terms.

>

> In CQL, a term must contain no spaces, though there is no technical

> reason why I couldn't relax this in future and have multi-word terms

> as in SBVR. The implementation problem is the same one that currently

> prevents me using more than a single adjective before and/or after

> a term.

>

> You'll note that although my Readings are composite objects, I don't

> actually show the decomposition, as SBVR does in section 8.3.4.

> Instead I use placeholders by incorporating the ordinals of each

> RoleRef into the reading text encased in curly brackets as NORMA

> does (e.g. "{0} has {1}").

>

> > I prefer to define the has synonym- relationship at the term level.

> >

>

> My use of the word Synonym is incorrect, as you point out.

>

> I wanted to have just a single fact type "Term designates Concept",

> but that can't provide an identifier for Concept (even if you objectify

> it as Designation and add "Designation is primary"), and I don't want

> to use a surrogate identifier (ConceptId). So instead I have a primary

> designation and AlternateDesignation. I've changed the readings to

> show that.

>

> Your Synonym fact type is derivable from these two. I prefer not to

> include derived fact types on the diagrams though. In fact, neither

> NORMA nor CQL currently handles the relational mapping correctly

> if you do. Also, your constraints on Synonym were insufficient.

> If instead I drop AlternateDesignation and add Synonym, several

> new constraints are needed to make it work correctly. It's simpler

> the way it is.

>

> > It's possible that a term neither designates a concept nor a role.

> >

>

> I believe that would be an error - unless we define new things that

> can be designated by a Term. You might want to do that of course,

> but them we'd revise the model. However, to make that possible, I'll

> remove the mandatory aspect and leave exclusion.

>

> > A term might have no synonyms.

> >

>

> Yes. Or a concept might have no alternate designations, same thing.

>

> > Additional textual rules must be added to enforce that a term and

> > its synonyms must belong to at most one vocabulary

> >

>

> No - the whole idea here is to allow terms from more than one vocabulary

> to designate the same concept. This is how multi-lingual and overlapping

> vocabularies are defined. This is not just for translation; in some

> organisations

> customers might be referred to as users or as clients, by different

> groups

> of people.

>

> > I think is better to derive the fact type Term has synonym-Term, if

> > it is useful.

> >

>

> Yes, I agree. But I won't show the derivation on my version of the

> diagram,

> if you don't mind. It's hard enough to read already, without that! The

> fragment

> I have now is as shown below.

>

> Clifford Heath, Data Constellation, http://dataconstellation.com

> Agile Information Management and Design.

>