[urn] Incorporating other identifiers into URIs

This message is a follow-on to several conversations.  I am attempting
to make it understandable without any previous context.

I address the question of "incorporating" identifiers defined by other
systems into URIs generally, not just URNs.  E.g., constructing a URN
that incorporates a Universal Product Code barcode number.

It seems to me that the cases of names (URNs) and locators (URLs) are
different.  In the case of URLs, the entity that creates the URL will
need to coordinate with the entity that creates the resource that the
URL locates.  Because of that coordination, the exact details of how the
external identifier is incorporated into the URL will necessarily be
resolved by that coordination, possibly not consistently between
different instances, but the necessary coordination will force a
workable solution.

In the case of URNs, the requirements of uniqueness and long-term
stability mean that we need to consider how such incorporation is done
rather carefully.

In regard to the *semantics*, I think it is reasonable to state in the
registration that the semantics are entirely delegated to the maintainer
of the external identifier.  A statement like

    The URN "urn:foobar:upc:nnnnnnnnnnnn" names the Universal Product
    Code nnnnnnnnnnnn.

seems to me to be well-defined, and it doesn't infringe on the authority
of the Universal Produce Code organization, because it slavishly follows
whatever that authority says about nnnnnnnnnnnn.

*Syntactically*, such an incorporation should be aware of any
"normalization" rules that are used for the external identifier.  E.g.,
ISBNs are usually written with hyphens, and for any particular ISBN,
there is a "standard" way to place the hyphens.  There is also a
10-digit version which has a canonical embedding into the 13-digit
version.  Consideration of these factors appears in the definition of
lexical equivalence for the urn:isbn namespace, and suggests that if an
ISBN is incorporated into a URN, hyphens should be deleted and the
10-digit forms converted into 13-digit forms.

Similar considerations are addressed in the current urn:glue proposal.

John Klensin raises the issue of change control.  Thinking about this,
the only general solution I can think of is this:  Where the
registration specifies that a certain portion of certain URNs is, or is
derived from, an external identifier, the registration must state the
specification of the eternal identifier and the particular version.

This is a necessity because there is no assurance that a later version
of the external identifier can be successfully incorporated into a URN
via a transformation rule that was created without the awareness of the
later version of the external identifier.

In practice, the URN namespace will want to track the definition of the
external identifier, but it seems that in order to do so, the maintainer
of the namespace will have to make any consequent changes to the
transformation rules and update the registration.

Dale

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]