Re: UNSPSC - and code lists in general

[Terry Allen <tallen@sonic.net>]

William Kammerer wrote:
| After I pooh-poohed David RR Webber's suggestion of having "a central
| location that people can reference [to find applicable code lists],"
| mostly because there's just so darn many code lists by so many different
| agencies, Mark Crawford, of LMI Logistics Management Institute, wrote in
| to say:
...

The key point is that there need not be, and should not be, any
"central repository".  All the code lists should be available from
SOME repository, but there is no need for them to be available
from the same one.  Competition in offering repository services
is desireable, and we want a system of distributed repositories.

| Mark:
| 
| We'd have to ask the Repository folks whether "one of the premises of
| ebXML is that the repository will provide a business (initiating party)
| with the ability to download a potential partners profile and process
| model(s) to create transaction(s)."  But it sure sounds reasonable to
| me.  I've had a real hard time going through the ebxml Registry and
| Repository Part 1- Business Domain v1-0 document at
| http://www.ebxml.org/specdrafts/RegRepv1-0.pdf because it's so darn slow
| to render in Adobe.  Are you having the same problem? Maybe they could
| rebuild the PDF file from the original Word document.  Anyway this is
| the specification with all the stick figures and talk about "actors."
| That went over my head.

Yes, this is only one of several mooted documents.  Don't worry.
...
| As Bob Miller has explained in the past on Core Components, there's a
| couple different types of code lists: 1) Text alias, 2) element alias,
| and 3) reference service; see
| http://lists.ebxml.org/archives/ebxml-core/200007/msg00073.html.

Whatever is to be stored can be stored in the kind of repository
we're looking to specify.
...
| But I thought David RR Webber and I were talking about the first type of
| code list (the text alias) and sometimes the third type (the reference
| service, as in UOM), generally promulgated by some type of external
| agency or standards body.  These would just have to be cataloged as they
| are encountered.  And it would be wishful thinking to think the creator

They are going to have to be cast into some XML encoding to be really
useful.  

| will produce an XML rendition of the code list; as a matter of fact, the
| list may be too big to do so - as in the case of SCACs, UPC/EANs, etc.

I don't think that's too much to ask, nor that even the list of UPCs
is too big to encode in XML.  However, You might be able to get along
by using the existing format.

| The best we can hope for is a nice annotation in the repository to tell
| you what one means by a "SCAC code" and where to find more information,
| much as we see in Appendix A: Code Sources of the ASC X12 manual.

One could do that too.

| And in the real world, your trading partner rarely needs access to all
| the possible codes, even for the smaller, finite lists like Unit of
| Measure.  If you deal only in Eaches, Barrels and gallons today in
| EDIFACT or X12, your EDI implementation guide probably has the
| restricted list defined for the elements in question.  Then your trading
| partner is saved the trouble of tracking down the UOM list.  Actually,
| with all of Bob Miller's concern about "semantics," maybe he has in mind
| some kind of exotic system which will take my "barrels" and convert them
| to your preferred "liters."

Conversion is a service built on top of, not a part of, a repository.
You do need access to the list of English measures, at least once (so
it can be built into your application).  Other lists change at varying
rates, so you need to know what their time to live is.

| Other times, you or your trading partner deal with only a certain few
| motor carriers.  There's no need to buy the entire NMFTA SCAC code list
| to get the few 4 character motor carrier codes you use.  Those few codes
| are known because your carriers will tell you what they are (every
| carrier knows his own SCAC), and you would put them in your own "schema"
| or "guideline" or whatever.  And that's another point: many lists are
| for sale only and are unlikely to be "shared" in the ebXML global
| repository - the best you can hope for is a link to the people doing the
| selling.

There will be no "ebXML global repository".  There will be many 
repositories.  And if code list providers want their code lists to
be useful, they will have to provide access to them over the Internet.
That doesn't mean they can't charge for access - this is one of the
information types best suited to making a profit from on the Internet.
There are many such examples (look around for information on the
hundreds of thousands of U.S. municipal bond issues and you'll find
that it's ALL available only by subscription).

Finally, each code list will need a description of its semantics
and "representation" (format) per ISO 11179 if we want to make it
useful in an XML context.

regards, Terry Allen


Terry Allen                             
Document Engineering Group               
Commerce One, Inc.
Mountain View, Calif.
tallen[at]sonic.net