Re: Proposed UUID Equivalence Mapping Methodology

[Philip Goatly <philip.goatly@bolero.net>]

Hello,

  Are you assuming there is a 1 to 1 equivalence between data elements in
standards ?

   There may be limited/no?  mappability between 2 'standards' because a)
they are not conceived at the same level of granularity,
or b)because there may be differences in cardinality or c)because there is a
Gap where one standard has element which is not needed in the other
standard. etc, etc.


Cheers, Phil

Bolero.net
----- Original Message -----
From: "Petit, John" <jpetit@kpmg.com>
To: <ebxml-core@lists.ebxml.org>
Sent: Thursday, March 22, 2001 6:33 PM
Subject: Proposed UUID Equivalence Mapping Methodology


> UUID mapping allows a schema (DTD, SOX, EDI, etc.) author to equate any
> number of their schema elements to another registered set of schema
elements
> via UUIDs. UUID mapping has been discussed within CC for some time, and
> alluded to in several documents, but it has yet to be fully addressed by
the
> hard working, but over-burdened, CC group. Without overstepping my bounds,
> but in the interest of time as Vienna is quickly approaching, I propose
that
> three, simple XML documents be included in the Registry. These three XML
> documents will allow basic UUID mapping between ebXML user documents and
> classification systems (ISO, ANSI, DUNS, etc.):
> * UUIDEquivalence.xml
> * UUIDAssociatedMaps.xml
> * UUIDTransformationRules.xml
> For those who would like some background on how UUID mapping will be
> utilized with in the ebXML framework, see the following section "Role of
> UUID Mapping."
>
> UUIDEquivalence.xml: This document captures the mapping information. As
> ebXML will be interfacing with EDI, DTDs, Schemas, SOX, etc, such simple
> equations have a wide use. It allows any group of UUIDs to be equated,
even
> if they do not belong to separate schemas. The "DestinationRegistry"
> attribute is optional, and would only be used if referring to UUIDs
outside
> the local Registry. We are not defining how the translation will be made,
> only providing the basic data for that transformation. It is up to the
agent
> software to determine how to translate the documents.  While these docs
can
> be created by hand or from any number of tools, I imagine that graphical
> editors will eventually surface to aid in the creation of UUID maps. Also
> optional is the use of a TransformationRule (described below).
>
> <Equivalences DocUUID=" [UUID] ">
> <Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
> " DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
> <Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
> " DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
> <Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
> " DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
> <Equivalence UUIDLocalSource=" [UUID]  "  UUIDDestination=" [UUID]
> " DestinationRegistry=" [URL] " TransformationRule=" [UUID] "/>
> </Equivalences>
>
> UUIDAssociatedMaps.xml: For any given UUID (identified by the
"ForWhichUUID"
> attribute), there may be any number of equivalencies made. For example, an
> element within a product catalog may be equated to several different
product
> catalog schemas. In seeking to construct a reference chain between two
> schemas, an agent would have to check all the equivalence maps for a given
> element.  For more information on reference chains, see section below.
>
> <AssociationCollection>
> <AssociatedMaps ForWhichUUID=" [UUID]  ">
> <AssociatedMap UUID=" [UUID]  "/>
> <AssociatedMap UUID=" [UUID]  "/>
> <AssociatedMap UUID=" [UUID]  "/>
> </AssociatedMaps>
> </AssociationCollection>
>
> UUIDTransformationRules.xml: Optional transformation rules can be used in
> situations in which there are cardinality discrepancies, data format
> changes, and value splitting/joining. The rule format is unrestricted
> (JavaScript, XSLT, Java, etc.). As there will be many situations in which
> the transformation is the same algorithm or rule, then being able to
select
> rules separately aids in code reuse. A set of format codes should be
defined
> so that agents will be able to recognize the various formats. Again, it is
> up the agent software to be able to process the transformation rules.
>
> <TransformationRules>
> <TransformationRule RuleUUID=" [UUID] " >
> <LocalSourceToDestination format="[format]" [Optional
> external doc reference]> [rule] </LocalSourceToDestination>
> <DestinationToLocalSource format="[format]" [Optional
> external doc reference]> [rule] </DestinationToLocalSource>
> </TransformationRule>
> <TransformationRule RuleUUID=" [UUID] " >
> <LocalSourceToDestination format="[format]" [Optional
> external doc reference]> [rule] </LocalSourceToDestination>
> <DestinationToLocalSource format="[format]" [Optional
> external doc reference]> [rule] </DestinationToLocalSource>
> </TransformationRule>
> </TransformationRules>
>
>
> Role of UUID Mapping: The ability to map one ebXML user document to
another
> based on UUIDs will solve many problems facing ebXML. UUID mapping will
aid
> in joining heterogeneous document types within a single document category
> (ex.: search all real estate listings even though they have different tag
> structures). Foreign languages, even structuring simple elements such as
> partner info can and probably will be tagged and structured differently.
> These maps capture the conceptual leap that a human can make but that an
> agent cannot make in equating individual elements. ebXML has been designed
> in a very loose fashion so that industries can define their own data
> structures and use a variety of technologies to do so. While this
looseness
> is broadly appealing, it presents some serious concerns in terms of basic
> data interoperability. This system of UUID mapping is also loose, as there
> is no requirement that documents be mapped at all. However, it will allow
> ebXML to grow organically. Like microfilaments in a root system,
eventually
> a contiguous net of connections will be formed.
>
> Such maps could also bridge various classification systems such as ISO,
> ANSI, etc.
>
> getHierarchy() function: This would return the nesting structure of a
given
> element or UUID.
>
> UUID Reference Chains: Lets say for example that two companies have
> registered ebXML documents that they want to translate between in order to
> do business (Purchase Order forms, etc.). By checking the UUID Association
> Maps, an automated search agent can begin to search through all the
> registries that these documents are mapped to until it finds a common link
> between the two documents. Essentially this is long process of "if
document
> A = B and B = C and C = D and D = E, then A = E." This is a UUID reference
> chain. As ebXML grows, and more and more documents are mapped, this sort
of
> agent based translation will become more and more robust.
>
>
> Cheers, John Petit
>
>
****************************************************************************
*
> The information in this email is confidential and may be legally
privileged.
> It is intended solely for the addressee. Access to this email by anyone
else
> is unauthorized.
>
> If you are not the intended recipient, any disclosure, copying,
distribution
> or any action taken or omitted to be taken in reliance on it, is
prohibited
> and may be unlawful. When addressed to our clients any opinions or advice
> contained in this email are subject to the terms and conditions expressed
in
> the governing KPMG client engagement letter.
>
****************************************************************************
*
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>