Re: More on a UML based presentation syntax for OWL

Evan Wallace wrote:
> 
> 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].

Agreed. Someone borrowed my reference guide and dit not return it.
 
> 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.

OWL will have primitive classes. As UML "class" stands for a primitive
class we should just call them "class" in OWL as well. Defined classes
could be out of scope for the UML presentation syntax (I included an
example in my note, but it has uses a self defined stereotype, of which
the semantics is not defined by UML).
   
> 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.

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

Agreed, see also my reply to Chris. I actually should have used the
class reference style (only show the class definition once; if you need
it more than once use a single-compartment class reference with just the
class name). 

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

No disagreement here. 
 
> 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].

The note should have said that we need the "association class' notation
for specifying transitivity. I like the "association as class" style
very much. It is true that it is not forbidding to draw generalization
arrows between association lines, but it makes the diagrams less clear
(at least from my perspective).

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

Will correct this. 
 
> 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.

Agreed. My note gives a misleadingly simple solution, which does not
work in general. This needs some rethinking. 
 
> 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.

A more mature version of this UML presentation syntax should surely
incorporate work from the efforts you mention. A UML profile for OWL
would be a great thing. 
 
Thanks for the feedback, Guus

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

-- 
A. Th. Schreiber, SWI, University of Amsterdam, Roetersstraat 15
NL-1018 WB Amsterdam, The Netherlands, Tel: +31 20 525 6793 
Fax: +31 20 525 6896; E-mail: schreiber@swi.psy.uva.nl
WWW: http://www.swi.psy.uva.nl/usr/Schreiber/home.html

Received on Thursday, 23 May 2002 09:43:32 UTC