Workbook on Digital Private Papers > Administrative and preservation metadata > Persistent identifiers

Persistent identifiers

Uniform Resource Name (URN)

Background

The URN concept originated in 1994 with RFC 1737, 'Functional Requirements for Uniform Resource Names', and a syntax was developed in 1997 (in RFC 2141). The functional requirements include:

URNs are therefore intended as persistent, location-independent resource identifiers, with the capacity for incorporating many different identifier schemes. They remain globally unique and persistent even when the resource becomes unavailable or ceases to exist.

URN syntax

A URN always begins with the 'urn' declaration followed by a colon, and takes the following form:

URN:[Namespace Identifier (NID)]:[Namespace Specific String (NSS)]

Example (urn representing the ISBN of a Hansard Society publication called A Strategic Guide for Online MPs):
urn:isbn:0900432160

NID The Namespace Identifier (NID) identifies which namespace is being used, and it comes from the URN Registry maintained by the Internet Assigned Numbers Authority (IANA). This registry lists existing naming schemes, by no means all of which were created specifically for the digital environment, e.g. ISBN, International Standard Serial Number (ISSN) and National Bibliographic Numbers (NBN, a namespace assigned to national libraries for integrating different identification schemes into the same identifier namespace). The NID can consist of letters, numbers and hyphens.

NSS The Namespace Specific String (NSS) follows the NID and is preceded by a colon. The NSS can consist of any characters which may have to be encoded, using the same encoding method as URLs, and the form it takes is dependent on the namespace it comes from (e.g. a string of numbers in the case of ISBN).

Resolving URNs

URNs were developed to be independent of any one resolution service. A number of different approaches have been proposed, although as yet there is no universal resolution service for URNs. This poses an obstacle to their widespread adoption, and there is also some disagreement within the Web and Internet community over whether URNs are necessary at all.

Maintenance and adoption

In order to use URNs as persistent identifiers, an organisation can either work within an existing URN initiative which has been assigned a NID, or (where a new, globally unique approach to identifiers has been developed) obtain a new NID, through a standardised application procedure. The URN Registry gives an indication of URN uptake to date; it includes some major international identifier schemes for resources, people and organisations.

Advantages and disadvantages of URNs

Advantages

  • URNs are flexible and easy to construct: the NSS can take any form, meaning that other namespaces can easily be mapped into URNs, yet global uniqueness is ensured as long as the NSS is unique within the NID.
  • The URN is an open standard and is technology independent.
  • Whilst no universal resolver of URNs has yet been developed, they can be used with the DNS and HTTP: a URN can be coded into a URL, and a proxy server used to route URN requests to a host server, enabling users to resolve URNs using a standard web browser.

Disadvantages

  • The lack of a universal resolver has hindered the takeup of URNs.
  • The ongoing lack of consensus about the value of URNs means that there may be a question mark over their long-term future.
  • Existing NIDs may not be suitable for dealing with personal digital archives, so it may be necessary to establish a new NID before using the URN system; this involves developing (to a detailed level) a new identifier scheme and submitting it before joining the queue of NIDs awaiting approval.