RIM and RS Issue: Identifier Usage (UDDI and URN)

[Len Gallagher <LGallagher@nist.gov>]

ebXML Regrep,

I'd like to raise an issue we've discussed many times, but for which we've
never reached a satisfactory resolution. I'm proposing that we consider
adding URN identifiers to the Registry/Repository specs for Phase 2, after
Vienna.

ISSUE

What are the relevant benefits of a machine friendly identifier( e.g. UUID)
versus a human friendly identifier (e.g. URN).

Here are some relevant references:

  for UUID:  http://www.dsps.net/uuid.html

  for URN:   http://www.ietf.org/rfc/rfc2141.txt

RIM (version 0.60) References to UDDI:  Line 375 page 13

RS (version 0.88) References to UDDI: Section 7.3.1, page 22-23, lines 522-536


CURRENT STATUS

RIM and RS currently require that every RegistryObject have a UUID. The
assumption is that clients can provide a UUID for their submissions and
that this UUID will be globally unique. If a client does not submit one,
then the server will generate one.

Currently there is no guaranteed substitute for UUID in any class. If a
client wants to guarantee that a specific Registry object be identified,
the client must first obtain and then use the UUID for that object.

There is a facility for ExternalIdentifier (RIM Section 7.8, page 21), but
that is an optional facility for storing other identifiers supplied by a
client. Presently, this facility does not require a human friendly
identifier for registry entry or repository item. 


MY PROBLEM

I don't think that UDDI can be relied on successfully for human usage. It's
128 bits long and has no semantic content discernable to the human user. A
human will have to memorize 32 hexidecimal digits in order to isolate a
single UDDI.

If I want to find all of the RegistryEntry instances submitted by my
organization (NIST), I will have to supply its UDDI, or do a query to first
determine the UDDI, and then a second query to return what I want using it.

Why can't I use a human friendly globally unique identifier such as
"urn:usgov:nist" to identify NIST instead of the UDDI assigned to NIST by
some Registry. And if I want to identify registry entries or repository
items submitted by NIST, why can't I define my own globally unique URN's to
reference them instead of having to invent 128 bit UUID's?  Or rely on the
Registry to supply meaningless UDDI's for my use.

I envision purchase orders being identified by a human friendly URN, e.g. 

   urn:org:mycompany:po:ver123

in addition to a machine friendly UUID, e.g.

    A234567D-B12-8C9-48D-1234567890AB

Using the URN, even if I don't know exactly the purchase order I'm looking
for, I can use our AdhocQuery mechanism on RegistryEntry to look for
registry entries that satisfy a URN "startsWith" "urn:org:mycompany" and
objectType="PurchaseOrder" to get a list of purchase orders from "mycompany".


DISCUSSION

I admit the machine efficiency of using fixed-length numeric identifiers
and support their required use in ebXML specifications, especially for
maintaining many-to-many associations among objects. When software is
communicating with other software, nothing is better. But, if software is
communicating with a human, and the human needs to remember an identifier
for future reference, UUID's won't work!

Why can't our ebXML specification support both machine efficient
identifiers (e.g. UUID) and human friendly identifiers (e.g. URN)? The UDDI
identifiers can be used to support many-to-many associations among objects
and the URN identifiers can be used when a result is presented to a human. 

Why not give some freedom to Submitting Organizations to provide
semantically useful URN's for their registered objects?


PROPOSAL (for Phase 2)

The ID attribute of RegistryObject is required to be a UUID. Let this
remain unchanged! But make it less visible to human users. Instead
encourage human interfaces to depend more on semantically meaningful URN's
to reference registry entries or repository items. Also let the software
that communicates with the human turn around and use the same
human-supplied identifier when communicating with the Registry.

The contentURI attribute of RegistryEntry is required to be resolvable to a
locator so that it can be used by arbitrary web browsers without assistance
from a Registry Client. Let this remain unchanged! The need for URN is
separate from the need for this contentURI attribute.

Add a new attribute to RegistryEntry and to Organization, call it URN. Make
this a required attribute just like ID and let it be supplied by the
Submitting Organization if they like, or let it be generated by the
Registry if one is not supplied. 

NOTE: I suggest putting this attribute on RegistryEntry and on
Organization, but NOT on RegistryObject, because I don't necessarily want a
one-to-one correspondence between ID and URN. For example, a registry entry
and its corresponding repository item may share the same URN, but if
repository items are stored in the Registry they will necessarily have
different UUID's because they are different objects. The URN attribute
would be an alternate key for each class. Thus two registry entries or two
organizations could not share the same URN.

The Registry would be required to maintain the association between the URN
and the UUID for each object. 


ADVANTAGES

With a single URN shared by both a repository item and the registry entry
for that repository item, the user can use the same URN to get whichever
item they want returned, e.g.

  getRegistryEntry(URN="urn:org:myobject") 

will return the registry entry instance and

  getRepositoryItem(URN="urn:org:myobject") 

will return the repository item instance. The user need not memorize two
separate and unrelated UDDI values, or submit multiple queries to get the
appropriate UDDI's, if they want both objects! 

Also, it's possible that an Organization and the CPP describing that
organization may share the same URN, but that's an implementation issue. So
it's possible that NIST, the CPP registry entry for NIST, and the CPP
repository item for NIST, may all share the same URN, e.g.
"urn:usgov:nist". There is no ambiguity because each has a separate UUID
and RegistryServices will always make clear what is being asked for when
the URN is used as a reference.

Clients could depend on being able to use any one of the 3 attributes (ID,
URN, contentURI) to retrieve desired objects from the Registry.


**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************