RE: UUID Semantic Equivalence Mapping

["Petit, John" <jpetit@kpmg.com>]

In response to 1) below: the mapping WOULD refer to specific entities such
as Shipper and its French equivalent, not generic ones.

In response to 2) below: It is my understanding that the ebXML specification
already has a good method of BP discovery and compare. It is the atomic
level of schema comparison that is missing (again the French schema author
equation to a Japanese one...)

-jp
-----Original Message-----
From: Mike Rawlins [mailto:rawlins@metronet.com]
Sent: Wednesday, March 21, 2001 9:13 AM
To: ebxml-core@lists.ebxml.org
Subject: Re: UUID Semantic Equivalence Mapping


I was cleaning out my inbox when I came across this message.  I couldn't
find any
replies.  Am I correct in assuming that this discussion has not gone any
further?

I would like to make two observations:

1)   If CC entities are defined as generic entities with type codes to
indicate
usage, rather than as abstract entities with more specific CCs reflecting
usage,
cross-referencing will be harder.  For example, it will be easier to
cross-reference Shipper with it's French equivalent than it would be to
cross-reference Party with type SH to Partie (sic?) with type whatever.
(Forgive
my ignorance of French!).

2)   Cross-referencing schemas only solves part of the problem.  In order to
solve the whole problem one must also be able to translate/compare encoded
BP
models.  That, I fear, will be a much more difficult task.

"Petit, John" wrote:

> At the Vancouver meeting it was agreed that a method for mapping the
> elements of one DTD or schema to another should be specified. It was
agreed
> that this would be done using the UUIDs assigned by the registry. This
part
> of the CC spec would allow automated agents to programmatically create
> equivalence maps between differing schemas. This VERY important aspect of
> eCommerce has to be addressed and soon if we are to make the May deadline.
>
> Without this last piece of the puzzle, automated agents will have no way
of
> determining the semantic equivalence from one schema to the next. For
> example, we talked about the language issue as some length. One company my
> use Thai another may use Spanish for the same schema. If they both point
to
> a French equivalent, then an agent could make the data translation between
> the two of them. This, combined with a nesting function (getHierarchy),
> which gives the elements nesting place in the document, can go a ways
> towards determining semantic meaning.
>
> What is the status of this?
>
> Cheers, John Petit
> Manager, KPMG
> XMLfs
> Office: 970 728 9468
> Mobile: 312 961 8956
>
****************************************************************************
*
> 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.
>
****************************************************************************
*

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
*****************************************************************************
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.         
*****************************************************************************