DATE: Dec. 3, 1999
REVISED:
NAME:Renaming of Subfield $u to Uniform Resource Identifier (URI) in Field 856 in MARC 21 Formats
SOURCE:Library of Congress
SUMMARY:This paper proposes making subfield $g (Uniform Resource Name) obsolete in favor of recording both URLs and URNs in subfield $u. The name of the subfield would be changed to "Uniform Resource Identifier (URI)".
KEYWORDS:Field 856 (All formats); Electronic Location and Access; Uniform Resource Identifier; URN; Subfield $g, in field 856; Subfield $u, in field 856
RELATED:99-08 (June 1999); 97-9 (June 1997)
STATUS/COMMENTS:
12/3/99 - Forwarded to the MARC Advisory Committee for discussion at the January 2000 MARBI meetings.
1/16/00 - Results of MARC Advisory Committee discussion - Approved.
2/11/00 - Results of LC/NLC review - Approved.
PROPOSAL NO. 2000-02:Renaming of field 856 subfield $u
1. BACKGROUND
Proposal No. 97-9 ( Renaming of subfield 856$u to accommodate URNs) was presented to the MARC Advisory Committee in June 1997. It suggested changing the name of 856$u to Uniform Resource Identifier (URI) to accommodate both URLs and URNs and adding an indicator value blank (#) to show that the access method is not provided for use with a URN. When the paper was discussed some participants felt that a separate subfield should be defined for URNs, rather than using subfield $u because of concern about their different functionality and how current systems would handle them if in the same subfield. A representative of the Internet Engineering Task Force who has worked on URNs cautioned against defining separate subfields, since URNs and URLs act the same way programmatically, and that future browsers will be able to handle both. However, although there was initially some support for the proposal, the final decision was to use a separate subfield. Subfield $g was redefined as URN, having been previously defined as Electronic Name End of range but unused.
Proposal No. 99-08 (Defining URL/URN Subfields in the MARC 21 Bibliographic Format ) discussed the definition of subfields in several other fields for URIs. The options presented were using separate subfields for URL and URN in fields 555, 583, and 76X-78X or using a single subfield. The proposal was unanimously approved in favor of a single subfield in fields 555 and 583. At the time it was suggested that the decision to define a separate subfield for URN in field 856 be reconsidered.
2.UNIFORM RESOURCE IDENTIFIERS
Current thinking in the World Wide Web Consortium (W3C) considers the distinction between URL and URN not meaningful. The term URI (Uniform Resource Identifier) seems to be in widespread use, referring to both concepts, and URIs are considered to be self-identifying. Although many browsers may not be able to currently resolve URNs, many do give an error message when resolution is attempted.
Given current thinking about identifiers and the approach taken in Proposal No. 99-08 (definition of a single URI subfield in fields 555 and 583), it is proposed that field 856 subfield $g be made obsolete and subfield $u be used for both a URL and a URN. Since 856 subfield $u is currently non-repeatable, it would have to be made repeatable and the format would stipulate that it could only be repeated if both a URN and a URL were recorded, not for repeated URLs. Since the two identifiers are self-identifying (a URN is identified by "urn:" as an initial string and a URL by a protocol such as "http:") it is possible that a system could enforce this if desired, although it would require extra programming.
Although in the discussion of Proposal No. 97-9 to include URNs in subfield $u, OCLC was opposed to using a single subfield because of the need to change their software, OCLC has since expressed support for the current proposal to use a single subfield. Essentially we know more about URNs and how they might be resolved now than we did then.
The Library of Congress, which initiated the proposal to define an element to record URNs (in this case, handles), has about 2500 records that have used subfield $g. If this proposal is approved these would either need to be changed or would be considered an obsolete use of the subfield. It is not recommended that the subfield be deleted or reused, since it is not clear whether others have used it.
Because it is possible to record both a URL and a URN for the same resource, subfield $u, which was made non-repeatable in Proposal No. 99-06, would need to be made repeatable. The format would stipulate that the subfield may not be repeated if two URLs need to be recorded (another 856 field is used), but that it could be repeated if both a URL and URN were needed. In the case of two URNs, repeatability must be possible, since two may apply to the same resource (e.g. a DOI and a handle).
3.PROPOSED CHANGES
In the MARC 21 formats:
Subfield $u contains the Uniform Resource <Identifier>[Locator] (<URI>[URL]), which provides electronic access data in a standard syntax. This data can be used for automated access to an electronic item using one of the Internet protocols <or by resolution of a URN>. Field 856 is structured to allow for the creation of a URL from the concatenation of other separate field 856 subfields. Subfield $u may be used instead of those separate subfields or in addition to them. <Subfield $u may be repeated only if both a URN and a URL or more than one URN are recorded.> The field is repeated if more than one URL needs to be recorded.
Library of Congress