OMG Ontology Metamodel Definition Review

I have now provisionally reviewed most of the OMG’s Ontology Definition
Metamodel (ODM) document and on first reading consider section 14 (ER
Metamodel) to be a recognised subset of the UML which, as such, does not
warrant significant comment. Bob Lojek (IBM) has also kindly reviewed
section 10 (UML2 Metamodel) and his findings are appended at the end of
this mail.

Firstly I must state that I consider the ODM paper to be a broad and
significant embodiment of current thinking on the representation of
ontologies. It extensively collates and articulates a number of
perspectives that are of great value and I especially like the material
presented in section 7 (Usage Scenarios and Goals). I find, however, the
material presented in section 8 (Design Rationale) and 9 (ODM Overview) to
be somewhat misdirected.

Section 8.2 presents reasoning as to why the ODM cannot be fully
represented in the UML, specifically stating a number of acknowledged
weaknesses within the language. Nevertheless I think that this is being
somewhat unfair and one must remember two important points about the UML as
a descriptive tool:

o     Firstly a primary purpose of the UML is ‘U’nification. This, by
definition means that it has to cover a lot of ground, hence loosing out on
specialisation in some cases in favour of a deliberately generalised
approach. The paper acknowledges this fact but does not appear to convey
the true values behind a unified approach to modelling.
o     Secondly the UML is a living ‘L’anguage and as such it should be
viewed as an evolving entity in its own right,  capable of change to meet
the requirements of most of the new, valid contexts in which it might be
used. Just because the UML 2 does not natively support specific concepts
required for the accurate representation of certain types of ontology does
not mean that it should or will not in the future. Perhaps, therefore, it
should be job of this Working Group to recommend amendments for inclusion
in later versions of the UML. If this means wholesale architectural changes
or the introduction of completely new schematic representations then so be
it. Most agree that graphical ontology conceptualisation needs to be based
closely around a Direct Graph theme and even if either Profiling or
Stereotyping cannot accomplish this directly in the UML 2 for more
specialised ontologies, the mapping of predicate associations is central to
its ethos and culture of those who use it professionally for whatever
purpose as part of their daily practices. Adding more types of graphing
schemes to cope for formal and specialised ontology representation is
hardly going to be rejected out of hand.

Nevertheless, I agree in particular that there are problems with cross
meta-level representation in the UML as it currently stands and that these
indeed may well cause barriers to successful ontology modelling.
Nevertheless such problems have been encountered a number of times already
in the modelling community and the use of proper and structured object
referencing mechanisms has traditionally surmounted such problems.
Admittedly this adds a layer of complexity on top of any raw ontology
itself, but that is the nature of the beast – formal representation often
needs additional ‘straight jackets’ to accommodate more specialised ways of

So my preference would not be to construct the ODM as ‘an aggregate of
equal and independent metamodels’ (as described and illustrated in 8.4 and
9.0). Instead I think that a ‘hub and spoke’ based model would be more
valuable, with the UML acting as the hub. Where features of the five
remaining metamodels cannot be represented directly, then emphasis should
be placed on either constructing new UML mechanisms for direct
representation or establishing suitable compromises and translations for
the purpose of unification. The reasoning behind this approach comes purely
form the huge gains that unification brings and not out of any preference
for the UML as a descriptive medium. ‘Pick your poison then drink’ should
be the message, so long as everyone drinks the same poison. Then at least
we can all meet in hell afterwards and compare notes, right?!

From my point of view the UML, for all its faults, has proved its worth
many times over in the hard faced commercial reality that is significant
systems’ development. The same is not yet true of ontology representation
and embodiment, yet its potential is plainly apparent to all who take the
time to investigate properly. If, as I suspect we all agree, we want to
make the power of knowledge representation, through graphical ontology
modelling, available to a much wider audience, then perhaps now is the time
to be pragmatic, rather than academic, and allow the UML to maintain the
upper hand? Surely only the most adventurous gamblers amongst us would not
admit that, for now, the UML is safest ‘bet in town’.


Bob Lojek wrote:


Here are my comments:

Talk to you tomorrow

Cheers, Bob

The approach has 4 levels of abstraction called metalevels,

M0, M1, M2 and M3; each is increasingly abstract as Mn increases and
decomposable in the opposite direction.

10.2.1 UML Kernel

Page 64: "There is no direct linkage between Association and Class. The
linkage is mediated by Property."

In the M1 model, why are association stereotypes not used, although table
11 and 12 indicate they are?

10.2.2 Class and Property - Basics

Page 67: "That is there are cases in which a relational database
implementation would use a
compound key to identify an instance of a class."

This is a conditional association, for example a foreign key that points to
several primary keys depending on runtime values. Shouldn't this be
described a the M0 level?

In the example

(Embedded image moved to file: pic04092.jpg)

I would stereotype the association as <<enrolled>>  and perpaps the
property as well. This will make it easier to process to downstream

Also the relationship of grade to enrolled is unclear to me, looking at the
diagram and this table.

(Embedded image moved to file: pic16522.jpg)

10.2.3 More Advanced Concepts

How will namespaces be addressed in the UML model? We are, for example,
using packages.

This is basically a comparison between OWL and UML 2, why not go back to
the language definition of OWL and map the coressponding UML equivilants to
it. This was done in "Table 18 Common Features of UML and OWL" but in the
opposite direction.


Phil Tetlow
Senior Consultant
IBM Business Consulting Services
Mobile. (+44) 7740 923328

Received on Tuesday, 25 January 2005 13:49:59 UTC