OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC