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.

2 of 2 Photo(s)