RE: ebXML Representtion of Metadata

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

DW writes ...

I suggest you go and take an entry from either X12 or EDIFACT codes and
elements and attempt to generate the RDF for it.

If you get any meaningful results you can share them with us.  I believe
you
will rapidly find that RDF is a solution looking for a problem and is not
generally applicable to what you perceive as the actual problem you are 
hoping to solve here.

MILR Responds:

A seemingly fair request, but some caution is required in addressing the
request.  It is important to note that ebXML is not about the business of
representing X12 or EDIFACT codes and elements.  On the other hand,
X12/EDIFACT codes and elements (and other higher level structures) are in
fact about the same task of representing business information.

My first observation is that if I were to map EDI codes and elements to XML
Elements, it would not be a one-to-one mapping.  As you might expect of the
outgoing Chair of X12C, I've been giving considerable thought to the EDI/XML
mapping problem. Certainly, I would arrive at a mapping that bore some
familiar resemblance to the EDI data structures.  Of course, traditional EDI
doesn't even begin to support Object Oriented technology.  So before I could
map some specific EDI construct, I would first need to lay some groundwork
by defining some fundamental Objects useful in representing something like
the EDI data constructs.  Perhaps the first set of objects I would define
would be those that accomodated data type.  That itself is complicated by
the fact that X12 and EDIFACT do not agree on such types (e.g., X12 has a
Date and a Time type, EDIFACT does not).  To maintain my sanity, I would
define a base set of data types from a semantic viewpoint (stealing from XML
Schema perhaps).  If that didn't satisfy the X12/EDIFACT crowd, I would
derive subclasses from these primitive classes as to satisfy their
temperaments.

X12/EDIFACT Code lists are an interesting breed deserving of special
attention.  Code lists come in several flavors, each of which may require
the definition of a subclass of a more primitive code list class.  Some code
list flavors I find interesting are:

o Fully enuerable code lists versus indefinitely enumerable code lists
(e.g., X12 DE 336 Terms Type Code is fully enumerable; DUNS Number is not
fully enumerable.

o Prefix code lists, whose span of semantic control extends beyond a single
information item. (E.g., DE 98, Entity Identifier COde, which has semantic
values such as 'Ship To')

o Couplet code lists, whose span of semantic control extends to a single
information item. (E.g., DE 235 Product/Service ID Qualifier, which is
coupled with DE 234 Product/Service ID and has values such as Batch Number).
This one is particularly interesting, as the value it controls may in turn
also be a code list value, scuh as a DUNS number.  Yet another distinctive
class to deal with.

O Modifer code lists, which provide semantic context to a value. (E.g., DE
355, Unit or Basis of Measurement, which has semantic values such as
'meters'.  Note that even these values have subgroupings, as for example
'pounds' and 'meters' relate to two differnt kinds of measurements.

It is important to observe that each individual code list value has its own
semantic identity and properties. So for example, the semantic 'Ship To'
might be represented in one or more code lists, and might also be
represented and used as a standalone XML element.

It is also important to note that all of this preliminary class definition
stuff is a prerequisite to any effort to define the units and components of
business data in a structured manner.  

Many folks who come from a non-EDI background fail to comprehend the
complexities of business data and semantics. And when confronted by these
complexities, some believe they can wish the complexities away, or just
throw them away and force business to live with he resulting simplicities.
Not going to happen!

The good news is that these complexities can be captured in business models
replete with canned processes for dealing with the complexities such that
they are no longer in the purview of the typical user.  A parallel example
in the computer world is the production of GUI's for human interaction with
computers.  There is nothing simple about the software underlying the
construction of these GUI's, yet the software interfaces are sufficiently
simple that we can use them as tools to build relatively friendly user
interfaces. 

All this said, don't expect me to provide what you request in any full blown
sense - that's a team effort size project.  But you can count me in on the
team.

Cheers,
         Bob