ebxml-architecture message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: a new UID discussion


yep...well stated Bob.
Scott 

-----Original Message-----
From: Miller, Robert (GXS)
To: ''ebxml-architecture@lists.ebxml.org' '
Sent: 11/15/00 10:51 AM
Subject: RE: a new UID discussion

I believe the intent of UID's is to provide a determinate path to
metadata
associated with the defined element.  While there may be instances in
which
a user-defined element has exactly the same metadata (no more, no less),
I
think more commonly the metadata will include some unique properties or
property values.  

To go back a few months in ebXML discussions, consider the case of
'CountryCode', and the multiple code sources for defining same.
Clearly,
the code tables associated with the different code sources differ, so
the
UID's for the elements have to differ, else we won't find the proper
code-table==>code-semantic translation.  On the other hand, the metadata
for
two codes derived from separate sources, both of which refer to exactly
the
same country (no more,no less) would be expected to reference the same
metadata for that country.  That is, the original element UID's, while
different, would lead down a path that unites for certain specific
countries.

In the earlier discussion of CountryCode, it was noted that some codes
do
not map one-for-one.  In those cases, the metadata might include
multiple
mappings and associated rules for making those mappings.

Similarly, when an industry extends or constricts a 'Core Component',
the
resulting restricted element would need its own UID.  It remains related
through its metadata to the 'Core Component' upon which it is based, but
it
also includes metadata unique to the derived element, especially
including
the derivation itself.

As a final example, suppose one defined an element 'fruit'.  A Florida
businessman defined an element 'oranges', but did not define 'fruit' for
his
application - only orange trees were planted in his grove.  A Washington
businessman defined an element 'apples' in his application - only apple
tress were planted in his orchard.  (Let's not get into why one plot of
land
is a 'grove' and the other an 'orchard').  With respect to the 'base'
element 'fruit' both 'apples' and 'oranges' share some semantic
properties.
But as we oft say, we're still dealing with apples and oranges here, and
they are not the same.  So in this example, we need at least three
UID's.

Some day, we need to work out the details of how metadata is
represented,
stored, and accessed.  It's not a simple problem to resolve.   Until
that is
done, the UID's we define may not provide as much automated mapping
assistance as envisioned.  But at least they will provide unique entry
points to such metadata as it evolves. W3C has defined RDF and RDF
Schema,
both of which include XML representations and address some aspects of
the
metadata representation problem.  Perhaps these will provide a starting
point, perhaps not.  In any event, until metadata representation is
standardized, any information pointed to by UID's will likely be of
limited
use in automating data transformations.

Cheers,
        Bob Miller 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC