Re: PartyId and Context

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Scott Hinkelman remains "skeptical that people will stop concocting
their own ad-hoc name schemes."  He "[believes] industries/groups will
continue to do this for reasons of lingo ,etc, regardless of how logical
it may be to have consistency," so he favors "allowing them to do it,
and minimize ebXML buy-in."  Scott loves URIs: "They are beautiful. But
I'm not yet convinced to mandate everyone to use it."

Industries and groups have, and will continue, to concoct their own
naming schemes since those schemes are devised to suit their own
purposes, of which ebXML is not one.  For example, Dun & Bradstreet
assigns company IDs for their business reports.  The National Motor
Freight Traffic Association assigns Standard Carrier Alpha Codes (SCAC)
to carriers used to report tariffs and other regulatory stuff. The
Uniform Code Council assigns UCS Comm IDs to all their members in the
grocery and retail industry.   The Federal Government assigns FEINs to
each employer. S.W.I.F.T. assigns the ISO 9362 Bank Identifier Code
(BIC), a universal identifier for financial institutions throughout the
world. Each bank in the U.S. has a Transit Routing Number assigned by
the American Bankers Association (ABA); it appears on your own checks.
There are any number of different codes to identify secondary and
post-secondary educational institutions.

Most of these IDs predate ebXML and EDI, and will be continue to be used
as the primary means of identifying organizations.  Nobody is going to
pay attention to any demand to get yet another ID just in order to
conduct e-business using ebXML.  They will want to use existing
identifiers.  We must accommodate that desire by making their usage
transparent.  It's not logical to have consistency for IDs, because it's
not at all necessary for ebXML's purposes.   As long as we can identify
a party by any of these types of existing schemes, we will have
succeeded in solving the PartyID and Context conundrum.

Charlie Fineman guesses "we could do an respectable job of identifying
the existing naming schemes and not have to evolve that list very much
in the future," and "this does not equate to ebXML [becoming] a registry
for the names themselves but it would require that ebXML be a 'registry'
(largely static) of the TYPES of names that can appear in party IDs."

There's no need for ebXML to become a registry for these schemes (e.g.,
DUNS, SCAC, EAN), because there is already EDIRA and ISO 6523.  And if
ISO 6523 doesn't list your favorite scheme, you might be able to find it
listed in the code lists for EDIFACT ISO 9735 D.E. 0007 routing
Identification Code or ANSI ASC X12's I05.  These three places are the
only "catalogs" of schemes that I know of that are readily available and
maintained on a regular basis. Maintenance is the key: if a business
identifier scheme is not found in one of these three places, there are
undoubtedly processes by which the BSI will add a new ICD to ISO 6523
for which they are the registration authority, the JSWG for ISO 9735's
list of schemes, and ANSI ASC X12 for X12's code list.

Taken together, these three places have hundreds of naming authorities
listed, though some are duplicated in all three (e.g., DUNS).  That's
not a terribly big number - Charlie is right: we could build our own
list based on what we find in ISO 6523, ISO 9735 and ANSI ASC X12.  But
why bother even with that much work?

Just provide some way of saying in <PartyID> that a particular party is
identified by organization ID "RDWY" that was assigned by the
registration authority whose ID is "02" defined as a code value in
Element I05 maintained by ANSI ASC X12.   Or, alternatively, give us
some way of saying that a particular party is identified by organization
ID "006998397" that was assigned by the registration authority whose ID
is "0060" defined as an ICD In ISO 6523.

Guess what? These two different organization IDs point to the same
company: Roadway Express in Akron, Ohio!  "RDWY" and "006998397" are
Roadway's SCAC and DUNS, respectively.  No mess, no fuss, and we
certainly don't have to bother the NMFTA (the RA for the SCAC) or Dun &
Bradstreet (the RA for the DUNS) asking them to register some type of
URI with the IANA. And Roadway doesn't have to screw around with
obtaining an "ebXML" identifier: they already have plenty of unique IDs,
why do they need another?  VANs already know how to get data to Roadway
Express using either solely the SCAC or the DUNS identifier.

I could go on and give more examples: organization ID "9254110060"
assigned by the RA identified by code "8" in ISO 9735 uniquely points to
the Kroger Co. in  Cincinnati, Ohio; "9254110060"  happens to be
Kroger's UCC Communications ID, and "8" in ISO 9735 says it was assigned
by the Uniform Code Council.  Want more? Organization ID "003658"
assigned by the RA identified by code "22" (Federal Interagency
Commission on Education) in ANSI ASC X12's Interchange ID Qualifier
uniquely points to the University of Texas at Austin.

Building a namespace containing definitions for hundreds of RA
identifiers, as Charlie might want, brings the concomitant headaches of
maintenance, especially keeping it in sync with the concurrent changes
to ISO 6523, ISO 9735 and ANSI ASC X12.  I presume the BizTalk Framework
2.0 requires this for the <address> BizTag.  But if we use the indirect
approach, which I think Scott Hinkelman was alluding to, we only have to
maintain a small list of three registry identifiers, denoting ISO 6523,
ISO 9735, and ANSI ASC X12.  I'll volunteer to build the namespace
element types:  how about "ISO_6523", "ISO_9735" and "ANSI"?  Then we're
back to what I originally suggested back in August, using a two-tiered
logical addressing structure, in "Trading Partner Logical Identification
based on EDIFACT or X12qualifiers," at
http://lists.ebxml.org/archives/ebxml-transport/200008/msg00073.html.
David Burdett may want to turn this into a URN, to which I have no
objection, e.g.:

urn:ebxml.org:partyid:context:ISO_9735:authority:8:value:9254110060.

That aside, David Burdett told Henry Lowe that "...we have been through
this loop once before in TRP. What is now happening is that other groups
such as RegRep and TP are getting involved which is actually very good.
I think that we should be able to come to resolution in a way which
meets everyones needs soon. This will be good as there will then
consistency across groups."  Well, not only do RegRep and TP have to be
dragged into <PartyID> definitions, but so does Core Components: see my
comments on the Party Identity aggregate at
http://lists.ebxml.org/archives/ebxml-core/200012/msg00019.html.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"