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
>