The following message includes comments on Discussion Paper No. 96
(Defining a URN in the USMARC Bibliographic Format) by Ron Daniel of Los
Alamos National Laboratories (forwarded with author's permission).

---------- Forwarded message ----------
>Date: Thu, 30 May 1996 15:37:20 -0600
>From: Ron Daniel <[log in to unmask]>
>Subject: Re: URNs
>
>Hi Cilla,
>
>Finally got a chance to look at Rebecca's paper on finding a place for
>URNs in the USMARC record. A few comments:
>
>>In mid-1995 the URI
>>Working Group was dissolved, since it had reached its original
>>goals and its current work was too broad to gain consensus.  It was
>>divided into separate working groups based on individual standards.
>
>Not quite true. The URI group was dissolved. New groups were not formed.
>Instead it was left for new groups to form if there was sufficient
>interest. The URC crowd has not yet created a charter that the IESG will
>accept. The URN crowd has not tried to create a charter, although there
>will be a BOF in Montreal to do so.
>
>>The Uniform Resource Name (URN) is the URI standard which deals
>>with naming conventions.
>
>There is no URN standard, proposed standard, draft standard, or even
>Internet draft at this time. Those of us who have been working on URNs
>in preparation for forming a group will have a set of drafts to release
>around the Montreal time frame, but they are not out yet.  However,
>they will follow the URI syntax that is an Internet standard (or at
>least a proposed standard - I forget just where it is on the standards
>track).
>
>>  A URN is the name of a resource that
>>identifies a unit of information independent of its location.
>>Other elements in the URI architecture include location (URL) and
>>description/metadata (URC, or Uniform Resource Characteristic).
>>A URN resolution service would be used to retrieve information
>>about the named resource.
>
>In our current proposals, you can issue several types of resolution
>request. N2C (URN to URC), N2L (URN to URL), N2R (URN to resource),...
>
>Not all resolvers will offer all services, but there is the notion that
>a client can resolve a URN to the resource without getting a URC in
>the middle of the process.
>
>Just to make things interesting, N2Ls (URN to URLs) and N2Rs (URN to resources)
>are also defined (but probably not widely implemented). This allows a set
>of URLs, or a set of resources, to be returned. (For N2Rs, think of getting
>the text, postscript, and HTML versions of a report, all wrapped up in a
>MIME multipart/alternative wrapper. It would be up to the client to pick one
>of the instances of the resource and present it to the user).
>
>
>>To use a URN, there must be a resolution service that can map the
>>name to the corresponding resource and return one or many
>>locations.
>
>or resources.
>
>
>>URN schemes.  The difficulty in bringing the URN work to an agreed-
>>upon standard has revolved around the resolution services that will
>>deploy them.  Currently there several URN schemes proposed which
>>have some aspects in common.  The major differences seem to lie in
>>the resolution mechanisms used.  These schemes are: 1) Resource
>>Cataloging and Distribution Service from the University of
>>Tennessee;  2) Handle scheme from the Corporation of National
>>Research Initiatives; 3) X-DNS-2 URN scheme, by Paul Hoffman and
>>Ron Daniel, based on the Internet Domain Name System; 4) URN
>>services, developed at OCLC and focusing on the syntax and
>>functions of URNs; 5) Path-URN scheme from the National Center for
>>Supercomputing Applications, which also makes use of the Internet
>>Domain Name System; 6) Whois++, which uses the existing Whois++
>>system as an Internet Directory Service.
>
>Handle still exists in pretty much the same form as it did. OCLC
>is more interested in PURLs and the PURL/Handle resolver than anything
>else. The rest of us are cooperating in what we call the "Knoxville
>framework" to seperate the resolution schemes from the naming schemes.
>D-Lib magazine (February I think) has an article on some of the Knoxville
>framework. More info will be coming out soon.
>
>
>>       URN implementors have agreed that there will be multiple URN
>>schemes, not a single canonical one.  The scheme used is encoded as
>>part of the URN.  URN groups reached outline agreement on most of
>>the major issues at a meeting of URN groups in October 1995 at the
>>University of Tennessee.  The consensus that was reached on URNs
>>results in the ability of users to be able to incorporate URNs from
>>existing naming schemes in documents and on-line systems without
>>having to be concerned that they will later have to reformat or
>>modify existing URNs.  The framework that was agreed upon will
>>continue to support existing URNs through resolution systems.  That
>>framework will evolve further and it allows for different naming
>>approaches.
>
>Right.
>
>
>>There are several fields that make up a URN:
>>       1)  The text string "URN:" opinions differ as to whether this
>>       should be included as part of the name.
>
>We are writing code to handle it both ways.
>
>>       2) SchemeID: type of naming scheme used (e.g. hdl for Handle;
>>       path for Path URN scheme)
>>       3) AuthorityID: name of individual, group or system within the
>>       SchemeID that is allowed to create ElementIDs. (This may be a
>>       domain name.)
>>       4) ElementID:  the element that will be resolved.  It might be
>>       considered the name of the object, although it becomes a name
>>       only in conjunction with the other elements.  There could be
>>       many objects with the same ElementID, so the SchemeID and
>>       AuthorityID are also necessary to make the URN unique.
>>Different naming schemes can use different formats.  The fields are
>>separated by colons.
>
>It is really [urn:]scheme:scheme-specific-string. (Optional "urn:"
>followed by schemeID, colon, and some string.  Some strings will have
>an authority ID, ":", Element ID. Others will not. ISBNs, for example,
>don't use a colon. MIME Content-IDs put the authority info at the end
>of the string, delimited by "@", just like an email address. I would
>soften the stuff on fields 3 and 4.
>
>
>
>
>>3.     URNs and MARC.
>>Although the URN has not yet become a definite standard and has not
>>become routinely deployed for all Internet resources, enough
>>consensus has emerged that the MARC community might consider how to
>>add the data element to the format.  The process of standards
>>approval is much different in the Internet Engineering Task Force
>>than in other standards communities that librarians may be familiar
>>with.  In the IETF world, proposed standards are broadly used
>>before actually being approved to ensure their viability.  The
>>USMARC Advisory Group approved field 856 before the URL was widely
>>accepted, but it was well under development.
>
>Right, but it was widely deployed. URNs are not. I think it is OK to
>look at how they might fit into USMARC, but there is not a pressing
>need to add them just yet.
>
>>There are two places in the MARC bibliographic format to consider
>>for a URN:
>>       1) In the 0XX block of fields for standard numbers and codes
>>       2) As a subfield of field 856.
>>
>>It seems most appropriate to include a URN at the record level,
>>that is in a 0XX field.  The URN has often been compared to an ISBN
>>or ISSN in that it is a persistent unique identifier.  Field 026
>>could be defined for a Uniform Resource Name.
>
>It may be important to distinguish between "unique" and "unambiguous" as
>applied to URNs. Any URN is supposed to apply to one chunk of intellectual
>content, called a resource, which may have different instantiations. However,
>any one resource may have multiple URNs. The most commonly used example of
>this is a URN for "current weather conditions". We can imagine a set
>of files that give weather conditions hourly. They have their own URNs.
>There is another URN that identifies the most recent one. I don't know
>how well such a URN fits into most catalog systems.  Just to make things
>even more fun, each hourly map might exist in GIF, JPEG, and PostScript.
>We could assign URNs to each of those formats as well.
>
>>Alternatively, a new subfield could be defined in field 856.  The
>>disadvantage to this approach is that it puts the URN at the copy
>>level (field 856 is in the holdings block of fields, similar to
>>field 852 for the library location).  Field 856 may be repeated for
>>each instance of the resource (e.g. if the resource were available
>>from different sites or available using different access methods).
>>If multiple 856 fields were in the record, the URN would then have
>>to be repeated in each.  The only subfields in field 856 that are
>>available are subfields $e and $y.  Recently it has been suggested
>>that PURLs would be used to resolve handles (one of the URN
>>schemes).  If this were the case, PURLs have been used in field
>>856.  In the INTERCAT database, the URL in subfield $u of the
>>contributed record is being shifted to subfield $z and a PURL
>>assigned and placed in 856$u.  This situation needs to be
>>considered in determining whether to use field 856 for the URN if
>>the PURL needs to be associated with the URN.  However, if an 0XX
>>field were used for URN, subfield $8 (Link and sequence number)
>>could be used to link to the 856 data.
>
>In the weather map scenario it might be appropriate to use both the
>0XX and 856 fields. 0XX could be for the URN that means "map at 11:00 AM
>EST", while the 856 fields could be for "JPEG version of 11 AM map",
>etc.
>
>>If field 026 were
>>used and if more than one URN were assigned to an object that was
>>considered one bibliographic entity for cataloging purposes, it is
>>possible that the URNs would have to be linked to the appropriate
>>electronic locations in field 856.  If so, linking subfield $8
>>could also be used for this purpose and a code for electronic link
>>would need to be defined.
>
>This probably bears more discussion, given the liklihood of
>multiple URNs being assigned to a resource.
>
>
>>4.     QUESTIONS
>>The following questions need to be considered.
>>
>>1.  Is it appropriate to define a field to accommodate the Uniform
>>Resource Name now?  Or should the USMARC Advisory Group wait until
>>institutions want to begin inputting them into their records?
>
>I counsel caution here. We have no experience with how URNs will
>be used, and I have tried to show they can be used in ways that
>violate the spirit of either the 856 or 0XX alternatives.
>
>>2.  How might libraries that become naming authorities want to
>>assign new URNs?  What sort of guidelines would be needed, and how
>>might they be developed? What types of institutions might become
>>naming authorities?
>
>Another question is what naming scheme might they want to follow?
>For lack of anything better, I am afraid that lots will want to use
>the current domain name hierarchy. Can you suggest a better naming
>system to use?
>
>>3.  If defined, should the URN be placed in field 026 (or other
>>0XX) or in a subfield of field 856? What are the implications of
>>that decision?
>
>If the link field allows both alternatives, that is the thing to
>look at most closely. The pure 0XX is probably not what you
>want to pursue, but neither is a pure 856 (in this Okie's opinion).
>
>
>Best regards,
>
>
>