From: Ken Baclawski (kenb@ccs.neu.edu)
Date: 01/23/01
I have edited the original messages and responses to focus on those issues
to which I am specifically responding here. -- Ken Baclawski
On Tue, 9 Jan 2001, Kogut, Paul A wrote:
[...]
> > The following are the missing notions from RDFS:
> >
> > 1. Resource is not explicitly addressed anywhere. Would this just be handled
> > implicitly?
> [Kogut, Paul A] Maybe this should be included in the profile. Resource is something very generic
> like ModelElement in UML. Any ideas?
[Baclawski, Ken] UML does not require a universal class (like the
Object class in Java). ModelElement is universal only for metaobjects,
not objects in general. Perhaps the best way to deal with the Resource
class is to introduce a universal class to UML. While UML does not
require such a class, it doesn't exclude the possibility either.
[...]
> > III. Properties of translations.
> >
> > What are the goals for the transformation? Should it be functional? Should it
> > be a two-way transformation? Should the two ways be inverses of each other?
> > While it is probably too much to expect that they be inverses, should they at
> > least be inverses up to semantic equivalence? Should they be bounded?
> >
> [Kogut, Paul A] How does this relate to the purpose and approach discussion
> on http://ubot.lockheedmartin.com/ubot/details/uml_to_daml.html?
[Baclawski, Ken] The purpose and approach discussion is fine, but it is
not formal. I wanted to express the issues in a formal setting.
On http://ubot.lockheedmartin.com/ubot/details/uml_to_daml.html it states:
> 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.
[Baclawski, Ken] This seems to be saying that that the transformation will
be functional on DUML. Is this correct?
> 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.
[Baclawski, Ken] This seems to suggest that the transformation from DAML
to DUML will not be an inverse. Is that what you intended?
Can you clarify any of the other issues I raised?
> [Kogut, Paul A.]
> Can you provide an example
> of where this was addressed for some other translation between a
> pair of languages?
[Baclawski, Ken] It comes up when one is transforming data models. For
example, when one transforms from ER or extended ER models to the
relational model (or vice versa), or when one is transforming from an OO
class diagram to the relational model (or vice versa). Having developed
such a pair of transformations, a natural way to test them is to transform
a model and then transform it back. Maintaining semantic equivalence can
be difficult or even impossible, and it is easy for the transformations to
be unbounded.
For example, one can transform each entity of an ER diagram to a
relational table, and each relationship of an ER diagram to a relational
table. This seems to be the natural transformation from ER to RM. In the
reverse direction, each table is transformed to an entity, and each
referential integrity constraint is transformed to a relationship.
This seems to be the most natural transformation from RM to ER.
Unfortunately, this pair of transformations is unbounded.
In the case of UML and DAML, one would get unboundedness if the
transformation from DUML to DAML transformed association ends (roles) to
properties rather than transforming (binary) associations to properties.
> > To make these questions a little more precise, let me introduce some notation.
> > Write {DUML} for the set of all UML diagrams needed for expressing DAML
> > ontologies (including any UML stereotypes). Write {DAML} for the set of all
> > DAML ontologies. Now there are many inessential ways in which one could vary a
> > UML diagram (or a DAML ontology) without changing the underlying semantics.
> > For example, the order in which one defines classes should not matter, yet that
> > order is part of the XML serialization of either UML or DAML. Use the term
> > "semantic equivalence" to mean that two DUML diagrams (or two DAML ontologies)
> > differ only in inessential ways. For a DUML diagram D, write |D| for the size
> > of D (in some arbitrary unit, such as the number of characters in its file),
> > and similarly for a DAML ontology.
> >
> > Now a transformation from DUML to DAML is a map UA:{DUML}->{DAML}. By
> > definition of DUML, it is defined on every DUML diagram. A transformation from
> > DAML to DUML is a partial map AU:{DAML}->{DUML}. Both of these transformations
> > should preserve semantic equivalence: if A is semantically equivalent to B,
> > then UA(A) should be semantically equivalent to UA(B), and similarly for AU.
> > It is also reasonable to assume that for any DUML diagram A, AU should be
> > defined on UA(A) and AU(UA(A)) should be semantically equivalent to A.>
> > Similarly for DAML ontologies.
> >
> > Even under all of these assumptions, it does not follow that UA and AU will be
> > inverse maps. Indeed, they may be far from being inverses. Let us say that
> > such a pair of maps as above is bounded if for any DUML diagram A, the sequence
> > |A|, |UA(A)|, |AU(UA(A))|, ... is bounded and for any DAML ontology O on which
> > AU is defined, the sequence |O|, |AU(O)|, |UA(AU(O))|, ... is bounded. It is
> > certainly possible for the pair AU, UA to be unbounded. Unboundedness has been
> > observed in much simpler settings such as translations between ER diagrams and
> > relational schemas.
[...]
> > generalization -> subClassOf
> > stereotyped dependency between 2 associations -> subPropertyOf
> > generalization between stereotyped classes -> subPropertyOf
> >
> [Kogut, Paul A] How do you indicate in UML that a generalization is transitive? I think the best we can do
> here is make it clear that a nontransitive UML generalization is translated into a transitive subClassOf.
[Baclawski, Ken] Unfortunately, UML is not precise about this. Some of
the language in the standard seems to suggest that generalization is
transitive, but it never explicitly says it, and one can interpret the
standard either way. In Rational Rose (at least in my version of it), one
can specify a variety of different kinds of inheritance including:
public, private, protected, implementation, virtual, "friendship
required", and stereotypes. Virtual inheritance is what I was calling
transitive inheritance.
> > Again, the semantics are somewhat different. UML generalization need not be
> > transitive in general. For example, specifying that C is a generalization of B
> > and that B is a generalization of A does not imply that C is a generalization
> > of A. This reflects the fact that in some programming languages (such as C++),
> > the subclass relationship is not transitive by default (although one can
> > specify that it is transitive if desired). On the other hand, the RDFS
> > subClassOf property is always transitive.
[...]
> > tagged value on a class and association -> seeAlso
> > tagged value on a class and association -> isDefinedBy
> >
> [Kogut, Paul A] I don't understand the problem here. There would be 2 tagged values with
> different names.
>
> > These two are mapping the same notion in UML to different notions in DAML.
> > How would a translator distinguish these?
[Baclawski, Ken] Yes, that makes sense.
[...]
> > stereotype on an association -> TransitiveProperty
> >
> [Kogut, Paul A] What other features of a property do we want to specify for DAML?
[Baclawski, Ken] There are many: acyclic, symmetric, anti-symmetric,
partial order, etc. It is hard to tell whether any of these will be
incorporated into DAML, of course.
> > This is a feature of a property. Presumably one could specify other features
> > of a property which would also be interesting. Using a stereotype for this
> > would mean that one could only specify one feature. A tagged value seems more
> > natural for this.
This archive was generated by hypermail 2.1.4 : 03/26/02 EST