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