RE: ebXML Representtion of Metadata

["David S. Frankel" <dfrankel@gendev.com>]

The XMI specification is based on the the OMG Metaobject Facility (MOF).
The MOF is essentially a stripped-down version of the UML Core.  A
MOF-compliant metamodel is one that is described in terms of the MOF, i.e.
in terms of this stripped down UML.  Metamodel descriptions are essentially
UML class models without frills--just the basic constructs of UML are used,
i.e. classes, associations and subtyping. You can use UML tools to create
these metamodels.

XMI stipulates how to do the following: Given a metamodel expressed in terms
of the MOF (i.e. given a class model), deterministically derive the XML DTD
that can be used for exchanging models based on that metamodel.

For example, the official XML DTD for UML was generated this way.  UML
(which is also an OMG standard) is a MOF-compliant metamodel because it uses
the MOF's UML subset to describe itself.  The DTD was machine-generated
using the metamodel as input.  This DTD is used to exchange UML models.
Quite a few vendors, including Rational, support this DTD.

The new OMG Common Warehouse Metamodel's DTDs were generated this way as
well.  The Common Warehouse Metamodel is MOF-compliant, i.e. it's described
as a class model using the MOF's subset of the UML constructs.  The DTDs
were machine-generated.  These DTDs are used to exchange data models.
Oracle, IBM, Unisys, Hyperion, and others worked on this standard.

Recently the OMG also adopted a new MOF-compliant metamodel for CORBA, and
used the same auto-generation to produce the DTD for exchanging CORBA object
models.

The beauty of doing things this way is that the class model captures the
semantics of the metadata very robustly, because UML/MOF is very rich
semantically.  The model becomes the real reference point for the semantics
of the metadata and can be used to generate not only the XML representation,
but also other representations that become important.  The MOF-XML
mapping--i.e. the algorithms for generating XML DTDs from metamodels--is
only one of several MOF mappings.  There is a MOF-IDL mapping defined by the
OMG and Sun is working on a MOF-Java mapping.  This means that the same
source metamodel can be used to generate an XML DTD, or to generate IDL for
the objects in a CORBA repository that represent the metadata, or to
generate the Java interfaces for the objects in a Java repository that
represent the metadata.  Mappings will probably be defined to LDAP and other
conveyance technologies.

This approach scales over time because it is neutral to the conveyance
technology.  In fact, the MOF was defined before XML became popular.  When
XML came along it was relatively straightforward to define a mapping to it.

You may find it interesting to note that some of the vendors that are
implementing XMI use the metamodel to validate incoming XMI streams--the
mapping algorithms are that precise.

A while back Terry Allen posted a note to one of these lists in which he
analyzed XMI.  He listed some issues he had with XMI.  His issues weren't
with the basic idea, but with some particulars.  Steve Brodsky of IBM
recently posted a response to the email list (just before Brussels).  I
haven't seen any further discussion of XMI since.

The context of Terry Allen's note was a suggestion that had been made at
some point that the XMI algorithms could be used to generate the business
DTDs from UML models of the business information.  In other words, he was
addressing the prospect of using XMI at the *model* level, despite the fact
that heretofore it has been used primarily at the metamodel level.  I think
this is a good idea for the same reasons it works well for metadata.  A good
semantic UML model of the business information can be used as a fulcrum that
can be applied in other spaces besides the XML space, and the semantics
overall are much richer.  You can define invariants with OCL (UML's Object
Constraint Language) and this leads to having quite precise semantics for
the business information.

I hope that Terry and others take a look at the response that Steve posted
and that we can have a productive discussion about this.

--David Frankel

================================
David S. Frankel
Chief Scientist
Genesis Development Corporation
741 Santiago Court
Chico, CA 95973-8781 USA

+1 530 893-1100 voice
+1 530 893-1153 fax
dfrankel@gendev.com
http://www.gendev.com
================================

> -----Original Message-----
> From: owner-ebxml-architecture@lists.oasis-open.org
> [mailto:owner-ebxml-architecture@lists.oasis-open.org]On Behalf Of
> Miller, Robert (GXS)
> Sent: Tuesday, May 23, 2000 1:28 PM
> To: ebxml-core@lists.oasis-open.org; ebXML-Architecture List
> Cc: Iyengar, Sridhar
> Subject: RE: ebXML Representtion of Metadata
>
>
> A reasonable question. My read of the ebXML requirements suggest a bias
> toward using W3 Reocmmendations, and my search of same led me to RDF.  I
> liked what I saw.
>
> I have heard some of those discussions regarding use of XMI. My
> un-informed
> knowledge of XMI that it provides a method for representing a UML model in
> XML syntax. That seemed to me a narrower focus then RDF. As I'm unfamiliar
> with the XMI specifications, I am not now able to evaluate RDF vs
> XMI. I'll
> take action to correct that knowledge deficiency.  XMI spec is downloading
> now.
>
> Thank you for your comment.
>
> Cheers,
>         Bob
>
>
> -----Original Message-----
> From: Cory Casanave [mailto:cory-c@dataaccess.com]
> Sent: Tuesday, May 23, 2000 2:47 PM
> To: Miller, Robert (GXS); ebxml-core@lists.oasis-open.org;
> ebXML-Architecture List
> Cc: Iyengar, Sridhar
> Subject: RE: ebXML Representtion of Metadata
>
>
> I note that you do not list XMI in your list of considerations, have you
> looked at this?  XMI is the adopted OMG standard for representation of
> metadata in XML.  There has already been some discussion of using
> XMI within
> EbXml.  I am not as familiar with RDF and will take a look at it.
>
> Regards,
> Cory Casanave
> Data Access Technologies
>
> > -----Original Message-----
> > From:	Miller, Robert (GXS) [SMTP:Robert.Miller@gxs.ge.com]
> > Sent:	Tuesday, May 23, 2000 2:40 PM
> > To:	ebxml-core@lists.oasis-open.org; ebXML-Architecture List
> > Subject:	ebXML Representtion of Metadata
> >
> > Representation of Metadata in ebXML
> >
> > This submission is a proposal by the author, Bob Miller, and
> has not been
> > yet undergone review by the ebXML Project Teams.  As such, it has no
> > official standing.
> >
> > The ebXML requirement for interoperability among both existing
> and future
> > XML implementations imposes a functional requirement for the machine
> > recognition of semantic and syntactic properties of XML elements which
> > comprise compliant ebXML documents.  Such properties are
> commonly referred
> > to as metadata.
> >
> > XML 1.0 provides a basic capability for representing metadata
> via the use
> > of
> > attributes associated with XML elements.  The XML Schema work
> in progress
> > in
> > W3C provides a somewhat more sophisticated mechanism.  This work has not
> > yet
> > achieved the level of a W3C Recommendation.  The Resource Description
> > Framework (RDF) Model and Syntax Specification, which has
> reached the W3C
> > Candidate Recommendation level, is part of the W3C Metadata
> Activity, and
> > it
> > provides a broad capability for representing data objects.  It supports
> > the
> > concepts of object classes, superclasses, and subclasses, of common
> > properties (including constraints) of such objects, and of extension to
> > user
> > defined properties of such objects.
> >
> > Metadata defined in an RDF can be used to automatically generate an XML
> > DTD,
> > Schema, or other XML syntax useful in validating compliance of an XML
> > document to defined properties of the elements comprising the document.
> > Metadata defined in an RDF is itself representable in XML, and
> a concrete
> > syntax for such representation is defined in the RDF specification.
> >
> > Upon careful review of the XML DTD, XML Schema, and RDF
> specifications, I
> > conclude that the RDF specification is most capable of representing the
> > metadata properties of Core Components and other business data objects
> > defined by the ebXML specifications.
> >
> > To support this recommendation, I propose the following condition be
> > satisfied for any document which claims ebXML compliance:
> >
> > 				Compliance to ebXML specifications requires
> > that each XML element that appears in an XML document asserting ebXML
> > compliance shall:
> > *	provide a pointer, either as an explicit attribute definition in the
> > XML element usage instance or by prior reference to a default attribute
> > definition for the XML element to an RDF/XML representation of metadata
> > associated with the XML element
> > *	define in each referenced RDF at least such minimal properties as
> > may be specified as required for compliance by the ebXML specifications.
> >
> > The ebXML specification shall define a well known attribute
> name within a
> > namespace defined by the ebXML specification, to contain the pointer to
> > the
> > RDF metadata.  The ebXML specifcation shall also specify the names of
> > properties, in such namespaces as appropriate, which are to be used to
> > define specific metadata properties required or optional in the ebXML
> > specification.  Additional properties not defined by the ebXML
> > specification
> > may be provided in namespaces not defined by ebXML.  Such additional
> > properties shall be outside the scope of the ebXML specification
> >
> > I suggest that the attribute name chosen to represent this pointer be
> > named
> > 	'RDF'
> > prefaced of course by the namespace qualifier that identifies the ebXML
> > namespace.
> >
> > A key feature of this design is the storage of metadata associated with
> > business objects and core components in a common format approved by the
> > W3C
> > as a Candidate Recommendation, accessible as needed via a pointer
> > mechanism
> > associated with the individual XML elements which comprise a document.
> > For
> > an existing XML document defined without knowledge of ebXML
> requirements,
> > conformance to ebXML can be achieved through simple enrichment
> of the DTD
> > (or Schema) used to define the document.
> >
> > Also, minimal overhead is imposed on the processing of an ebXML document
> > when there is no business need to dynamically traverse the associated
> > metadata. In the normal case of repetitive use of a common business
> > document, traversal of the metadata would likely be a one-time activity
> > used
> > to establish mappings between the business application and the document
> > content.  Similarly, construction of a Schema to provide partial
> > validation
> > of document content would be a one-time activity.  The choice to apply
> > Schema validation to incoming or outgoing documents during testing and
> > during live production is left to user discretion.
> >
> >
> > In my opinion, the ebXML Core Components should assume
> responsibility for
> > specifying the required and optional ebXML RDF properties for
> use both in
> > the definition of Core Components and in the definition of other data
> > objects required to define an ebXML compliant document.
> >
> > The RDF specification is syntax neutral, and so meets the
> requirement that
> > Core Components work output should be syntax neutral.  Since a concrete
> > representation of RDF in XML also exists, there appears to be
> no need for
> > the Registry and Repository team to address the representation of the
> > output
> > of the Core Component team in XML syntax.  There may remain a
> need for the
> > Registry and Repository team to cooperate with the Business Process and
> > Core
> > Component teams to define the RDF representation of the output of the
> > Business Process team.
> >
> >
> > Cheers,
> >              Bob
> >
> >
> >
>