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
Having problems with message search?
Offline 
Send Email