draft UML profile for DAML

From: Kogut, Paul A (paul.a.kogut@lmco.com)
Date: 11/30/00

We have been working on conventions for modeling DAML ontologies in UML.
The profile below does not cover all of DAML-O but we feel it is time to get some
feedback on our approach from a wider audience. Graphical UML examples will
soon be available to help illustrate the approach described below. Special
thanks to Lewis Hart and Bill Holmes on this initial draft. 

Please post comments and questions on daml-graphical. 
When we reach a reasonable degree of consensus we will post 
the results to the rdf-logic mailing list. 



                            Draft UML Profile for DAML


The primary goal of this mapping is to support translation from UML class diagrams 
to DAML ontologies. The assumption is that the UML class diagrams were created
specifically for the purpose of designing DAML ontologies. This mapping
does not attempt to map all elements on a class diagram to DAML.
Legacy class diagrams that were not originally intended for DAML applications
can be partially translated or they can be modified for DAML purposes.
At some point in the future we may extend this profile to enable complete
translation of legacy class diagrams to DAML.
A secondary goal of this mapping is to support translation from DAML ontologies 
to UML. We anticipate that this translation is more difficult because some 
DAML keywords have multiple alternative renderings in UML.  



The approach taken is to use UML extensions (stereotypes and tagged values)
sparingly in cases where a model needs to explictly mark a specific DAML
element for translation purposes. A * denotes an extension which is part of 
this proposed UML profile for DAML.	

Determining the domain and range of a property from an association in a UML
class diagram is facilitated by modeling conventions. One approach is to use
navigability to indicate the direction of an association which determines the
domain and range. Navigability can be indicated in a model by an arrow
on an association end. If the association end is navigable then it should
also have a rolename. The property name is formed by concatenating
the association name with a rolename. An association with two-way navigability 
translates into two distinct inverse DAML properties.  

A second approach is not to use navigability and rolenames.
In this case the property name is the association name. The direction in which 
the association is drawn (which is explicitly indicated on the model as a 
name-direction arrow in some tools) determines the domain and range. 
In this approach, inverse properties must be drawn as separate UML associations.  

The table below shows two significantly different approaches for modeling 
subproperties. There is a tradeoff between adding more clutter to an 
integrated diagram vs. cross-referencing between separate diagrams 
showing a class hierarchy and a property hierarchy. After we gain more 
experience applying DAML, we can better decide whether to keep 
both approaches or drop one of them.

UML						DAML			Comments

--Terms imported from RDF/RDFS--

class						Class (RDFS)
instanceOf 			 		type (RDF)		annotation context
type of modelElement 				type (RDF)		ontology context
attribute 					Property (RDF)
association					Property (RDF)
generalization					subClassOf (RDFS)
stereotyped dependency between 2 associations* subPropertyOf (RDFS) 	simple hierarchy
generalization between stereotyped classes* 	subpropertyOf (RDFS)	complex hierarchy 

note						comment (RDFS)
name						label (RDFS)

tagged value on a class and association*		seeAlso (RDFS) 		
tagged value on a class and association*		isDefinedBy (RDFS)

attribute type: string				Literal (RDFS)			
attribute value					value (RDF)
initial value for an attribute			default

class containing the attribute			domain (RDFS)
source class of an association			domain (RDFS)
attribute type (primitive or class)			range (RDFS)
target class of an association			range (RDFS)


stereotyped dependency*			equivalentTo 		


stereotyped package*				Ontology 		
tagged value on a package*			versionInfo
import (dependency stereotype for packages) 	imports

--Facets of properties--

multiplicity (for association end) 	 		cardinality
multiplicity range Y..Z (for association end)	Y=minCardinality

association target end multiplicity= 0..1 or 1	UniqueProperty		
association source end multiplicity= 0..1 or 1	UnambiguousProperty	

stereotyped dependency between 2 associations* inverseOf
stereotype on an association* 			TransitiveProperty

This archive was generated by hypermail 2.1.4 : 03/26/02 EST