More on a UML based presentation syntax for OWL

Here are some comments on Guus Schrieber's UML based presentation
syntax document [1] per my action item.

First, it is worth noting that there has been considerable work done
exploring the potential to use UML for ontology development.  [2]
provides a short survey of this work (including the work of Sandpiper,
LMC, CODIP, etc.) with extensive web references.  A number of these
efforts defined mappings from UML to DAML.  One such mapping can be
found in [3] and another can be found directly on the UBOT website 
<http://ubot.lockheedmartin.com/ubot/details/uml_to_daml.html>.  We
should definitely compare our mapping to these if we continue to 
pursue this presentation syntax.  (BTW - the issue regarding the
mapping for property to UML associations was mentioned in both [2] and
[3], and is being discussed in the ongoing work for UML V2 --
see http://www.omg.org/uml for more on UML 2).

Second, my perspective on this mapping comes from experiences using
UML and its predecessors for conceptual modeling for the manufacturing
domain.  Important aspects of the mapping would therefore relate to
how natural the use of this presentation syntax would be for a person
with similar experience to my own.  In short, I think Guus' mapping
succeeds from this perspective.  But another important issue for me is
the exact form of the mapping.  I would like to see us define a UML
profile for OWL so that existing UML tools could be used to model OWL
ontologies which then could generate XMI renderings of the model
mappable to OWL transfer syntax.  Otherwise we may run into
intellectual property issues if we try to co-opt certain UML graphical
constructs for our own independent use (particularly if they have
different meaning from UML).

Specific comments on [1] follow:

UML reference

The "UML User Guide" mentioned at the end of the "Purpose of this
document" section is a tutorial and not a reference.  While the
canonical reference for UML 1.x is the OMG specification[4], I suggest
we use the "UML Reference Manual" [5] which is a sister publication to
the UML User Guide.  This is what I used to check the semantics and
notation for UML constructs used in [1].  

Primitive class note

UML classes are primitiveClasses.  After all the discussion regarding
primitive and defined classes on the webont list, I am unsure that a
notion of primitive class will exist at all in OWL.  This seems like
it could be a problem for a UML presentation syntax.  At a minimum,
the issue will need to be clearly identified and explained for users
of the UML presentation syntax.

UML notation for generalization relationships

A minor comment: There are two more common notations for representing
a set of generalization relationships (the UML construct for defining
subclasses) than that shown in the figure labelled "A class with two
subclasses."  These are: the tree notation and a set of individual
straight arrows.  The mapping document should state that notation
shown are just examples and that the mapping doesn't prohibit other
UML notational options unless specifically stated.

Multiple appearances of a class

Many of the examples in [1] show a given class appearing multiple
times in a single diagram.  As Chris Welty pointed out, it is unusual
for this to occur in a single UML diagram.  It is, however; expected
that objects _will_ appear in multiple Class diagrams (making up a
single model) and that such appearances can introduce "additional
relationships and attachments to a class."  Furthermore, I didn't find
anything in the description of Class or Class Diagram in [5] which
precludes the style that Guus used in his examples.

Chris's cycle issue exists whether or not use of this style is
permitted.  Associations that "loop" like this (i.e. domain and range
are restricted to instances of the same class) are not uncommon in UML
models.  If OWL has a problem with this, then we would need to clearly
explain the problem and its work-around in the mapping document.

Cardinality on UML associations and OWL subset

UML allows a pretty flexible specification of cardinality
(UML:multiplicity range) for each side of an association.  This
flexibility is widely exploited in UML based domain models.
Therefore, whatever OWL language set is used to support the UML
presentation syntax should also fully support this expressiveness in
specifying local cardinality.

Association generalization relationships

According to [5] a pair of associations need not be association
classes in order to create a generalization (subtype) relationship
between them.  Thus it is not obvious that "The clearest way of
modelling a subproperty relation is to model the associations involved
as a UML association class" as claimed in [1] (perhaps this choice was
actually motivated more by the capabilities of particular tools then
by the features of UML).  It is true that modelling properties this
way would get us closer to representing this with a first class
object, but it fails to address the key concern motivating that goal.
Even association classes must have their end points tied to particular
classes (i.e. they still can't have an identity independent of the
classes that they will associate).

Having said all that, I don't disagree with this choice (modelling
properties with association classes).  Besides it still would be
necessary to do this in order to make use of the scheme for modelling
metaproperties shown in the "Transitive property" section of [1].

Notation for transitive metaproperty

This section states, "The instance-of relation is shown in UML through
a dependency with an <<instance>> stereotype."  According to [5,p412]
the terms here are switched.  It should read, "The instance
relationship is shown in UML through a dependency with an
<<instanceOf>> stereotype."  Note also that "<<instanceOf>>" should be
substituted in place of "<<instance>>" in all the figures where it
appears.

Disjoint constraint

The discussion and example using the predefined UML constraint
"disjoint" may be misleading to many readers.  This UML constraint
actually applies to a set of generalization relationships to a common
parent and not to a set of classes per se.  As such, it would normally
be shown as an annotation on a set of generalizations (again,
represented as a tree or a set of straight arrows).  Furthermore,
since UML classes don't all share common ancestry, applying such
constraints across arbitrary classes would not ordinarily be valid.


Summary:

As I mentioned before, I think that [1] is an excellent start at
creating a UML based presentation syntax for OWL.  The efforts noted in
[2] show that there is sufficient interest to justify developing such
a syntax.  A discussion of issues encountered when mapping between the
languages is covered in section 5 of [3] (in a few pages).  A couple
of the authors of these papers have offered to review the next
generation of Guus' paper when we are ready.  Finally, there is even 
mechanism and a constituency at OMG through which we could formalize the
mapping between these languages as a UML profile.  This would be done
after OWL was released as a proposed recommendation.



[1] "Scheiber. "A UML Presentation Syntax for OWL Lite".
http://www.swi.psy.uva.nl/usr/Schreiber/docs/owl-uml/owl-uml.html

[2] Kogut, Cranefield, Hart, Dutra, Baclawski, Kokar, and Smith.
"UML for Ontology Development"
<http://ubot.lockheedmartin.com/ubot/papers/publication/KER4.doc>
to appear in Knowledge Engineering Review Journal Special Issue on
Ontologies in Agent Systems

[3] Baclawski, Kokar, Kogut, Hart Smith Holmes, Letkowski, and Aronson
(2001) "Extending UML to Support Ontology Engineering for the Semantic Web"
Proc. of the Fourth International Conference on UML (UML2001),
<http://ubot.lockheedmartin.com/ubot/papers/publication/UMLOntology.pdf>

[4] OMG (2001). "Unified Modeling Language (UML) version 1.4."
<http://www.omg.org/technology/documents/formal/uml.htm>

[5] Rumbaugh, Jacobson, and Booch (1999).
"The Unified Modeling Language Reference Manual"
Addison-Wesley. ISBN 0-201-30998-X


*******

Evan K. Wallace
Manufacturing Systems Integration Division
NIST
ewallace@nist.gov

Received on Tuesday, 21 May 2002 11:32:09 UTC