RDF, RDFS vs UML, MOF, XMI etc

Folks,

some days ago I started an offline discussion with Stephen Cranefield
about RDF, UML and related issues. This discussion has been fairly
controversial, but I believe it contributes to the understanding of the
foundations and relationships between these technologies. Some of the
issues that have been raised may be relevant for extending and
formalizing RDFS. This posting contains the complete story so far. I
answered some of Stephen's questions on the basis of my understanding,
but many of you might disagree with the opinions below. I'm still
puzzling about answering the last Stephen's mail...

Sergey

(5 messages follow)
-------------------------------------------------------------------

Sergey,

I am very interested in your work on representing UML in RDF.  I am
involved
in an agent-based distributed information systems project in which we
are
using UML models as our ontologies.  We were planning to use the MOF and
XMI
as a basis for our ontology repository and related infrastructure,
however
there is very little MOF software available (only the MOF implementation
from DSTC in Australia which doesn't yet have support for importing and
exporting models via XMI).

I would be interested to know more about your work.  Do you have a
graphical
representations of your RDF-based UML metamodel and/or examples of
actual
UML models encoded using this scheme?  Do you have a way of importing
and
exporting models developed using tools such as Rational Rose to and from
your encoding?

Regards,
Stephen

------------------------------------------------------------------------
Stephen Cranefield                                 Phone: +64 3 479 8083
Department of Information Science                  Fax:         479 8311
University of Otago                                 
Dunedin, New Zealand         E-mail:
scranefield@infoscience.otago.ac.nz    
Information Science home page: http://www.otago.ac.nz/informationscience
------------------------------------------------------------------------



Stephen,

thanks for your interest. My UML work is still in a very preliminary
stage, I don't have any write-ups yet. RDF does not define custom
graphic representations for specific (meta)models. Thus, a graphical
representation used for UML/RDF looks as a pretty generic directed
labeled graph. I cannot draw right in this email, but imagine that you
have an arc for every statement below (X merged into the same node):

X --rdf:type--> Generalization
X ---child----> Class
X ---parent---> Classifier

This is how generalization would look like graphically. I'm working on
some state machine instances and will post them on the Web site
sometime. In fact, metamodels like State Machines that are defined using
Foundation/Core provide a fairly good example of how instances are
encoded (the State Machine schema can be viewed as an instance of Core).

I've just updated my Web page
(http://www-db.stanford.edu/~melnik/rdf/uml/) to include an example
showing a sample state machine. As you can see from this example,
DublinCore vocabulary (dc:Description) can be easily mixed with the
State Machine vocabulary (not violating the consistency of the model).
IMO, this is the major strength of RDF-based encodings.

Currently I don't have a way of importing/exporting UML over RDF from/to
XMI. Speaking frankly, I haven't even had a chance to use any tools that
support UML. I think having a converter to/from XMI would be great. It
should be a fairly straightforward thing to do, since in XMI "class"
names consistently alternate with names of association ends. The URLs
for UML/RDF were chosen to be suffixes of the tag names used in XMI.
Having a converter, existing tools could be used to create UML models
and UML/RDF could be leveraged to make UML truly Web-ready, not in the
crippled XMI-fashion...

Also, note that there is no special "encoding" behind the UML/RDF
mapping. The only thing I did was to create a URL for every identifiable
UML entity (e.g. http://www.omg.org/uml/1.3/Foundation.Core.Class or
http://www.omg.org/uml/1.3/Foundation.Data_Types.Integer). UML
association ends correspond to RDF properties, the rest is mechanical
conversion. I did this conversion for some important subsets of the
UML standard.

I'd be very glad if my work were useful to you. I'm also interested to
know more about your progress. Feel free to contact me if you have more
questions or ideas.

Best,
Sergey

------------------------------------------------------------


Sergey,

Thanks for your reply.  I was imagining that the schema could be
visualised
using the usual RDF notion with ovals for resources, arrows for
properties
and rectangles for literals.  However, I now see that I was
misunderstanding
the nature of your work: I had assumed that your metamodel would make
use of
existing RDF metaclasses such as rdfs:Class and properties such as
rdfs:subClassOf.  I now see that the only existing RDF property you make
use
of is of rdf:type.  Actually I am confused about how this can work. 
When
UML is defined using the MOF model, or by using UML itself as a
meta-metamodel, concepts such as inheritance, attributes and
associations
already exist in the meta-metamodelling language.  I am not familiar
enough
with RDF to be able to understand how your schema works without using
(for
example) rdfs:subClassOf.  In particular, I cannot see any inheritance
in
your schema.  How do you model the fact that a UML class is a
specialisation
of a UML classifier?  I don't understand your use of Classifier.feature
and
cannot find where this property is defined.  I would be grateful if you
could find the time to explain this to me.  Are there some resources in
your
schema that can be considered to be meta-meta model concepts and others
that
are UML concepts, or is this not the way it works?

By the way, your Web page makes the following statement:

> "The goal of this work is to make UML "RDF-compatible". This allows
> mixing and extending UML models and the language elements of UML itself
> on the Web in an open manner. XMI, the current standard for encoding UML
> in XML by OMG, does not offer this capability. It is based upon a
> hard-wired DTD.

You may be interested to hear the following argument against this claim,
put
forward by the PhD student Mariusz Nowostawski:

> The above is simply not true at all.
> 1. XMI is a mechanism to serialize MOF models (not UML models)
> 2. To "extend" UML one has to change its metamodel, which is "a
> language" in which UML is defined, so one needs to change a MOF model of
> UML. After the change one can serialize the changed MOF model, i.e. new
> UML using XMI easily, that what XMI is for.
> One can also serialize easily new models of this new UML, simply by
> generating new DTD for the new model of UML, and using the new one
> instead of the old one.
> 3. so called "hard-wired DTD" comes from the level "above", so after any
> change to the metalevel, the DTD will simply change accordingly.
> 4. XMI provides "type checking" and makes sure on the current level we
> are not going out of the constraints derived from the metalevel.
>
> It seems those guys want a more dynamic approach, and they want to mix
> UML + its metalevel in a single, dynamic flat structure of RDF.
> Personally I do not see why and how it might help in doing things "in
> open manner".  I do not see also how it might be used differently than
> XMI-based approach (I mean what can be done in this approach which
> cannot be done in XMI?).

I would be interested in hearing your response to this.

Regards,
Stephen


-------------------------------------------------------------

Stephen,

> ...
> I had assumed that your metamodel would make use of
> existing RDF metaclasses such as rdfs:Class and properties such as
> rdfs:subClassOf.  I now see that the only existing RDF property you make use
> of is of rdf:type.  Actually I am confused about how this can work.

This is exactly the desired effect (not that you are confused; that rdfs
is not used ;)

I may be very mistaken, but for me something like MOF does not make much
sense. There is some virtue in avoiding saying that the concept "class"
is an instance of itself, but not much. The discussion is just shifted
onto another "meta"-level, where the same situation has to be faced
again.

IMO people who are worried about "logical" consistency forget about the
"crystal-palace" nature of the mathematics: the set theory is formalized
using the predicate logic which relies upon the set theory. At some
point, people as well as machines need a built-in understanding of a few
basic concepts to communicate meaningfully. Mathematicians needed
centuries to develop such a "built-in understanding". For machines,
executable code can be a good approximation.

As to MOF, RDF and UML specificly:

Does RDFS deserve a superior role to define UML? Or the other way
around? For me, IMO, RDFS, MOF, UML Foundation/Core, OIL and a variety
of other "schema" models are on an equal footing; an ontology of an
ontology is still an ontology. Expressing one conceptual model in terms
of another makes sense for me only as a way of mapping one onto another.

> When
> UML is defined using the MOF model, or by using UML itself as a
> meta-metamodel, concepts such as inheritance, attributes and associations
> already exist in the meta-metamodelling language.  I am not familiar enough
> with RDF to be able to understand how your schema works without using (for
> example) rdfs:subClassOf.  In particular, I cannot see any inheritance in
> your schema. How do you model the fact that a UML class is a specialisation
> of a UML classifier?

Similarly to RDFS, I consider UML to have its own "built-in" concepts
with predefined semantics. Generalization is one of them. The expression

<Generalization>
  <Generalization.child rdf:resource="&c;Class"/>
  <Generalization.parent rdf:resource="&c;Classifier"/>
</Generalization>

from uml-core [1] corresponds to the statements:

X --rdf:type--> c:Generalization
X --c:Generalization.child--> c:Class
X --c:Generalization.parent--> c:Classifier

In other words, there exist an entity (X) that represents this specific
generalization instance. This entity is defined by its properties child,
whose value is Class and parent, which is the concept Classifier. If the
concept c:Generalization as well as c:Generalization.child and .parent
are considered to have well-defined, commonly agreed upon semantics, the
above statements start making sense.

This is exactly how rdfs:subClassOf works. Now: if you chose to "know" a
built-in concept rdfs:subClassOf and a number of other logical terms,
you could describe how the UML Generalization maps to rdfs:subClassOf
using the terms/vocabulary you know (which can refer to Java code, for
example).

> I don't understand your use of Classifier.feature and
> cannot find where this property is defined.  I would be grateful if you
> could find the time to explain this to me.

Classifier.feature is defined in uml-core [1] as an "AssociationEnd":

<Association>
  <Association.connection>
        <AssociationEnd rdf:ID="&c;Feature.owner">
          <AssociationEnd.type rdf:resource="&c;Classifier"/>
          <AssociationEnd.aggregation
rdf:resource="&d;AggregationKind.composite"/>
          <AssociationEnd.ordering
rdf:resource="&d;OrderingKind.ordered"/>
          <AssociationEnd.multiplicity rdf:resource="#0-1"/>
        </AssociationEnd>
  </Association.connection>
  <Association.connection>
        <AssociationEnd rdf:ID="&c;Classifier.feature">
        ==============================================
          <AssociationEnd.type rdf:resource="&c;Feature"/>
          <AssociationEnd.multiplicity rdf:resource="#0-*"/>
        </AssociationEnd>
  </Association.connection>
</Association>

The underlined markup above generates the statement:

c:Classifier.feature --rdf:type--> c:AssociationEnd

or without shortcuts:

http://www.omg.org/uml/1.3/Foundation.Core.Classifier.feature
---http://www.w3.org/1999/02/22-rdf-syntax-ns#type--->
http://www.omg.org/uml/1.3/Foundation.Core.AssociationEnd

defining Classifier.feature to "be-an" AssociationEnd.

> Are there some resources in your
> schema that can be considered to be meta-meta model concepts and others that
> are UML concepts, or is this not the way it works?

IMO meta-meta concepts are useless. RDFS "defines" itself using its own
metamodel; UML can do the same thing. MOF pretends to define UML, but
where is the vocabulary used in MOF defined? You could "define" MOF
using UML, but you get the same recursion as with RDFS, just over one
more iteration.

> By the way, your Web page makes the following statement:
> 
> > "The goal of this work is to make UML "RDF-compatible". This allows
> > mixing and extending UML models and the language elements of UML itself
> > on the Web in an open manner. XMI, the current standard for encoding UML
> > in XML by OMG, does not offer this capability. It is based upon a
> > hard-wired DTD.
> 
> You may be interested to hear the following argument against this claim, put
> forward by one of students (he's not a native English speaker, but I think
> he's written this pretty clearly):
> 
> > The above is simply not true at all.
> > 1. XMI is a mechanism to serialize MOF models (not UML models)

If I print out my state machine instance in XMI, I'm effectively
serializing a UML model.

The UML specs says it pretty clearly (section 6.1):

        The XMI DTD generated for UML is a physical mechanism for
interchanging
UML models
        conforming to the UML metamodel. ... When interchanging UML
models via
streams or files,
        this normative XMI DTD should be used.

> > 2. To "extend" UML one has to change its metamodel, which is "a
> > language" in which UML is defined, so one needs to change a MOF model of
> > UML. After the change one can serialize the changed MOF model, i.e. new
> > UML using XMI easily, that what XMI is for.
> > One can also serialize easily new models of this new UML, simply by
> > generating new DTD for the new model of UML, and using the new one
> > instead of the old one.
> > 3. so called "hard-wired DTD" comes from the level "above", so after any
> > change to the metalevel, the DTD will simply change accordingly.

With respect to this, I tend to take the pragmatic side: you cannot
solve the interoperability problem by generating a wealth of
incompatible DTDs (syntaxes). And who is going to do that? As "easy" and
"simple" as it sounds, I can hardly imagine a standards committee
keeping changing MOF upon requests and creating XMI DTDs on a daily
basis ;)

Moreover, I don't see a good reason for extending UML, let alone using
MOF for that. The conceptual model of UML is pretty sound. The only
thing which is really poor is its serialization. One can easily define
new classes and associations in UML. But I don't see a way to serialize
the instances of those new classes using the XMI specification (the only
couple of instances for which XMI works are concrete state machines, use
cases etc.) How would you define a class say Person and serialize an
instance of Person in XMI? Maybe I'm missing something...

> > 4. XMI provides "type checking" and makes sure on the current level we
> > are not going out of the constraints derived from the metalevel.

Type checking provided by DTDs is very limited (see introduction to XML
Schema).

> > It seems those guys want a more dynamic approach, and they want to mix
> > UML + its metalevel in a single, dynamic flat structure of RDF.
> > Personally I do not see why and how it might help in doing things "in
> > open manner".  I do not see also how it might be used differently than
> > XMI-based approach (I mean what can be done in this approach which
> > cannot be done in XMI?).

I illustrate a trivial advantage of UML/RDF over XMI in the example that
recently I added to my UML/RDF page [2]

> I would be interested in hearing your response to this.

Thank you Stephen and Mariusz for your comments. Some of
the issues that you raised are still very much unsolved. If you don't
mind, I'd like to make our discussion public and move it to the RDF
Interest Group mailing list. We're touching the rationale and logical
foundations of RDFS; some RDF folks may be particularly interested in
that.

Best,
Sergey

[1] http://www-db.stanford.edu/~melnik/rdf/uml/uml-core-20000507.rdf
[2] http://www-db.stanford.edu/~melnik/rdf/uml/


----------------------------------------------------------------


Sergey,

Thanks for the additional information about your work.

I am going to have to admit that I have a mathematics degree and
therefore
have been well indoctrinated in the utility of mathematical models.  I
don't
find your comments about the foundations of mathematics very convincing
as a
reason to abandon the only widely accepted and objective way of defining
the
meaning of a model.  Do you really think that UML is well-defined by its
official "semantics" document - which consists of English descriptions
of
the concepts in UML, with some additional constraints in OCL?  I believe
that any proposed model or metamodel needs clearly formulated semantics
(which usually means a mathematical basis).  In this way, others can
gain a
common understanding of its meaning and there should be no ambiguity and
no
well-formed syntactical expressions that have no meaning.

In particular, one of the simplest ways of thinking about the
"instance-of"
relationship that occurs between a element of a model and its type in
the
metamodel is one of set membership.  A class can be seen as a set of
instances and a metaclass is a set of classes.  It makes little sense
from
the semantic point of view to put sets of instances and sets of sets of
instances at the same modelling level - special mechanisms would need to
be
put in place to prevent relationships that make sense between classes
being
used between classes and metaclasses.  It would also break this simple
intuition of a class being a set of instances.

The above comments were from the theoretical point of view.  For a
practical
implementation I have no problem with different levels of the
metamodelling
hierarchy being flattened out so that concepts from the different levels
can
all be represented in a uniform way.  However, I think there still needs
to
be a clear understanding of how this implementation corresponds to the
theoretical account, and it doesn't help to have the concepts of class
and
metaclass represented by the same RDF resource.

> Similarly to RDFS, I consider UML to have its own "built-in" concepts
> with predefined semantics. Generalization is one of them. The expression
> 
> <Generalization>
>   <Generalization.child rdf:resource="&c;Class"/>
>   <Generalization.parent rdf:resource="&c;Classifier"/>
> </Generalization>
>
> from uml-core [1] corresponds to the statements:
> 
> X --rdf:type--> c:Generalization
> X --c:Generalization.child--> c:Class
> X --c:Generalization.parent--> c:Classifier
> 
> In other words, there exist an entity (X) that represents this specific
> generalization instance. This entity is defined by its properties child,
> whose value is Class and parent, which is the concept Classifier. If the
> concept c:Generalization as well as c:Generalization.child and .parent
> are considered to have well-defined, commonly agreed upon semantics, the
> above statements start making sense.

I agree with this, but I think you are talking here about representing a
generalisation relationship in a *model*.  However, your schema does not
seem to explicitly represent the generalisation relationships at the
metamodel level.  When I work with UML I find it very useful to look at
the
UML diagrams that are used to define the concepts in UML and how they
relate
to each other.  The diagrams tell me a lot about how to use UML.  It
doesn't
seem that this metalevel information about UML can be extracted from
your
schema, but perhaps this is not one of your aims, or the information is
in
there but is obscured (to the novice's eye) by the mixing of levels.

> Moreover, I don't see a good reason for extending UML, let alone using
> MOF for that. The conceptual model of UML is pretty sound. The only
> thing which is really poor is its serialization. One can easily define
> new classes and associations in UML. But I don't see a way to serialize
> the instances of those new classes using the XMI specification (the only
> couple of instances for which XMI works are concrete state machines, use
> cases etc.) How would you define a class say Person and serialize an
> instance of Person in XMI? Maybe I'm missing something...

This is exactly the problem we have been grappling with (and Mariusz, in
particular).  A
XMI DTD for UML is a general model encoding the concepts of UML (class,
association, generalisation).  That is because it is designed for
transporting models, not graphs of instances that correspond to some
model.
In other words, the DTD is at the wrong level of abstraction.

As UML contains object diagrams, it is possible to represent an object
of
class Person as an object diagram  and then serialise that via XMI.  The
problem is that the resulting XML file will contain separate elements
for
the instance, each attribute, the associations between the instance and
those attributes, the values of those attributes, and the associations
between the attributes and those values (I haven't actually tried this,
but
I assume this is what would happen based on the "Common Behavior:
Instances
and Links" diagram that contains the metamodel for UML object
diagrams).  It
would clearly be very cumbersome to parse this XML in order to
reconstruct
the object.

I believe that the solution is to develop standard ways of mapping from
models in UML to specialised DTDs (or, preferably, XML schemas).  Such a
schema would provide a direct encoding of your Person object that could
(with the right infrastructure) be directly unmarshalled into an
in-memory
object.  This is similar in spirit to OMG's XML/Value RFP
(http://www.omg.org/techprocess/meetings/schedule/XML_Value_RFP.html)
and
Sun's XML Data Binding JSR (http://java.sun.com/xml/docs/bind.pdf,
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_031_xmld.html).

I am attaching a couple of papers that discuss our interests in
communicating (within a FIPA-style distributed agent system)objects
and/or
knowledge about objects that correspond to some ontology defined using
UML.

> I illustrate a trivial advantage of UML/RDF over XMI in the example that
> recently I added to my UML/RDF page [2]

Surely this example just shows how flexible XML is - you can mix
statements
from different XML namespaces in a single document.  As a dc:Description
property can be associated with anything having a URL, you could also
add
this DC information to a document produced using XMI.  Of course the
resulting file could no longer be validated against the UML DTD, but
this
problem could be solved by putting the DC information in a separate
document
and by having some outer container document reference the two related
documents (I don't yet know enough about XML and DTDs to know exactly
how
this would be done, but it seems as if it should be a fairly minor
technical
issue - wishful thinking perhaps!).  Anyway, if you give up DTDs or
schemas,
naturally you gain in flexibility, but you also lose out on higher-level
parsing and typechecking support as well as the possibility of
model-specific marshalling and unmarshalling support.

> Thank you Stephen and Mariusz for your comments. Some of
> the issues that you raised are still very much unsolved. If you don't
> mind, I'd like to make our discussion public and move it to the RDF
> Interest Group mailing list. We're touching the rationale and logical
> foundations of RDFS; some RDF folks may be particularly interested in
> that.

I would be happy for you to do this, and so is Mariusz.
I should add that the opinions expressed above are not necessarily
shared by Mariusz (but I'll keep trying to convince him!).

Regards,
Stephen

Received on Sunday, 28 May 2000 00:17:36 UTC