Draft UML Profile for DAML Purpose 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. ----------------------------------------------------------------------------------- Approach 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) --Renamimg-- stereotyped dependency* equivalentTo --Ontologies-- 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 Z=maxCardinality 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