PERSISTENT IDENTIFICATION SYSTEMS
Part 1 :
Background
1. BACKGROUND
1.1 The distributed digital library
The WWW has produced a revolution in the availability and accessibility of electronic information for users of all types and has the potential to continue to effect vast changes in the way libraries, archives, publishers, etc. deliver information to their clients.
One of the benefits of the www for libraries is that it has enabled them to deliver services in a way undreamed of less than a decade ago. Digital collections can be delivered over open networks using standard, multipurpose software in the form of standard web browsers already on the desktops of their clientele. Prior to this development, the ability to deliver these kinds of services electronically was limited by the need to use (multiple) proprietary systems and to have some control over the software on the desktop of remote users.
The technology and infrastructure currently available makes possible for the first time a de facto distributed digital library, providing direct access to a multitude of resources through commonly available technology using open standards. Digital resources can be accessed directly by links embedded in databases, catalogues, indexes, gateways and by links embedded in other digital objects or resources.
Such a distributed digital library would consist of a vast range of digital resources housed and maintained by a variety of different institutions. Some born digital materials will be maintained and distributed by the publisher, some will be duplicated by archival institutions or taken over once the publisher no longer maintains them. Much of the material available from libraries and archives will be digitised versions of items in their own collections, other material will be produced specifically for public distribution, yet other material, initially produced as part of business operations, will be made available for public distribution. Libraries and archives will also make available archived materials.
The strength of this distributed model is that it leverages off an architecture that is open and almost universally deployed.
Its major weakness has now been apparent for several years and relates to the almost universal use on the web of identifiers that are based on the location of the digital resources they identify and which are therefore subject to change as resources move and systems change. For the open architecture digital library or archive, this is a critical flaw.
One of the keys to the development of a distributed digital library or archive is the ability to rely on the links between the digital resources to remain static over time, whether these are links embedded as citations in other resources or links embedded in metadata in bibliographies, indexes, and catalogues or in bookmarks and gateways. Much of the value of digital resources for scholarly communication lies in enabling resources to be cited reliably with actionable links over long periods of time. Libraries and archives collect for the long-term to support scholarly research and need to support access to materials beyond the life of current technology and possibly beyond the organisational structures which exist today.
Thus libraries, archives, academic institutions and publishers have an interest in the persistence of resource identification. Persistent naming is a characteristic of all open architecture digital library experiments. Persistent identifiers and their associated metadata are needed to support a variety of transactions including the search, retrieval, selection and use of digital objects.
There are two elements of the task of maintaining the availability of resources in the distributed digital library:-
- To preserve, or archive, the item in order to ensure that it survives;
- To maintain its accessibility to ensure that it can be located and displayed by those who wish to use it and that citations and links made to it continue to provide access to it.
The issue of persistent identification is primarily concerned with the second, but is also closely related to the first.
William Arms sums up the importance of persistent identifiers in his article on the Key concepts in the architecture of the digital library
Names are a vital building block for the digital library. Names are needed to identify digital objects, to register intellectual property in digital objects, and to record changes of ownership. They are required for citations, for information retrieval, and are used for links between objects.
1.2 Existing formal identifier schemes
There are many formal identifier or naming schemes which have been discussed in the context of the naming of digital resources (e.g. URIs, URNs, DOIs, Handles, ISBNs, ISSNs, SICIs, BICIs, ISWC, PII), although very few of these will be fully effective as persistent identifiers facilitating access to online resources in a distributed system unless they are either registered as URI naming schemes and supported by a resolution system or they are incorporated into another naming scheme which has some form of resolution system associated with it.
The importance of resolution cannot be overestimated. The strength of the existing URL/URI standard which supports most of the information on the www is the widely deployed resolution system in the form of the DNS (Domain Name System). Without a resolution system, requests using the identifier cannot be routed to the appropriate server and used to retrieve the resource, or a reasonable substitute for it in the form of metadata.
1.3 General URN/URI Issues
1.3.1 Uniform Resource Identifiers (URIs)
The identifiers used on the www at present are URIs. Two broad categories of URI, the URL and the URN, are described in RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax (August 1998).
A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute(s) of that resource. The term "Uniform Resource Name" (URN) refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable. RFC 2396, p.2.
Of these two categories, the only one that is widely deployed at present is the URL, and most resources currently on the www are described using a URL. As mentioned above, the URL generally describes a resource in terms of its current location.
It is the location-based nature of the URL that is its major weakness as a persistent identifier, since the identifier will change if the material is moved either to a different server or a different place in the file structure of the same server. If this happens, all links to this resource embedded in other documents or databases will cease to work. The volatility of material on the web generated by movement of files and re-organisation of sites, not to mention deletion of materials, has highlighted the difficulty in guaranteeing continuous access to materials in a system which uses a naming structure based on file location to provide that access.
1.3.2 Uniform Resource Names (URNs)
This need for persistence in the naming of networked resources was recognised early in the life of the Internet and has been the subject of discussion for several years within the IETF (Internet Engineering Task Force).
Work on the development of a unique identifier that would be independent of location and would remain permanent even though resources might move or disappear began at the same time as work was proceeding on the formalisation of URL schemes. The identifier was named the URN (Uniform Resource Name). However there was little agreement on the details of such a scheme and consensus on the syntax and semantics of the identifier remained elusive for a period of years. A specification outlining the minimum requirements of the URN, RFC 1737 Functional Requirements for Uniform Resource Names by K. Sollins and L. Masinter was issued in December 1994.
This document outlined a general agreement on the basic requirements for URNs (Uniform Resource Names) and by definition any useful persistent identifier scheme. These are:
Global uniqueness: The same URN will never be assigned to two different resources.
Persistence: It is intended that the lifetime of a URN be permanent. That is, the URN will be globally unique forever, and may well be used as a reference to a resource well beyond the lifetime of the resource it identifies or of any naming authority involved in the assignment of its name.
Scalability: URNs can be assigned to any resource that might conceivably be available on the network, for hundreds of years.
Legacy support: The scheme must permit the support of existing legacy naming systems, insofar as they satisfy the other requirements described here. For example, ISBN numbers, ISO public identifiers, and UPC product codes seem to satisfy the functional requirements, and allow an embedding that satisfies the syntactic requirements described here.
Extensibility: Any scheme for URNs must permit future extensions to the scheme.
Independence: It is solely the responsibility of a name issuing authority to determine the conditions under which it will issue a name.
Resolution: A URN will not impede resolution (translation into a URL, q.v.). To be more specific, for URNs that have corresponding URLs, there must be some feasible mechanism to translate a URN to a URL.
The RFC goes on to outline the necessary characteristics of a URN specification which would be required to meet this list of requirements, the most significant of which are:
To satisfy the requirements of uniqueness and scalability, name assignment is delegated to naming authorities, who may then assign names directly or delegate that authority to sub-authorities. Uniqueness is guaranteed by requiring each naming authority to guarantee uniqueness. The names of the naming authorities themselves are persistent and globally unique and top level authorities will be centrally registered.
and
It is strongly recommended that there be mapping between the names generated by each naming authority and URLs. At any specific time there will be zero or more URLs into which a particular URN can be mapped. The naming authority itself need not provide the mapping from URN to URL.
Although these general principles were accepted, reaching agreement on the detailed syntax of a URN was difficult, and in 1995, the URI group split into two, with a separate group working on the URN specification. The differences between the protagonists were evident at two levels. The first was a division between supporters of the URN concept and those who did not believe that there was a need for a URN. The latter believed that the URI could be managed to achieve the kind of persistence required. The second was a division among supporters of the URN concept who were having difficulty in reconciling their various implementation proposals in order to reach consensus on the details of the specification.
At the end of 1995, the implementers reached a broad consensus on the syntax of a URN and agreed to work towards a technical solution that would accommodate the needs of most users. Nevertheless it was May 1997 before URN Syntax was formally agreed upon and published in RFC 2141 - URN Syntax.
The syntax of the URN as expressed in RFC 2141 is as follows:
urn:<Namespace identifier (NID)>:<Namespace specific string (NSS)>
The NID, which must be registered and approved by IETF to avoid duplication, ensures the global uniqueness of the identifier. The namespace specific string can take any form specified by the naming authority provided that it is unique within that namespace and avoids the use of a small number of restricted characters as specified in the URN syntax, RFC 2141.
The simple structure of the identifier reflects recognition of the need to accommodate different requirements and different schemes. Because the local, or namespace specific, string can be in any form, the identifier structure allows maximum flexibility in the identifier while providing a mechanism to assure global uniqueness and facilitating interoperability between discrete systems.
1.3.3 Requirements for resolution
Despite the differences expressed over the form and utility of a URN, there is general agreement that there is a need to distinguish between naming schemes and resolution systems. That is to say that a naming scheme, as a procedure for creating unique URNs that conform to a specific syntax, is independent of the resolution service which resolves them to locate the resource. A naming scheme should not be tied to any specific resolution system and a resolution service should be capable of resolving a URN from any given name scheme.
This is consistent with the intentions behind the development of the URN. A persistent identifier, especially when used for archival data must of necessity be capable of outlasting any systems and protocols that are currently in use. However the lack of a commonly agreed upon resolution system is also a major obstacle to the wide deployment of URNs.
A variety of solutions have been proposed, including a new DNS resource record, NAPTR (Naming Authority PoinTeR), as described in RFC 2915, that provides rules for mapping parts of URIs to domain names. This was made obsolete by a revision and renaming of the proposal issued as an Internet draft in February 2001. The new proposal is named the Dynamic Delegation Discovery System (DDDS). The DDDS approach is to use the DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself.
The use of http proxy servers is also a possibility. However wide deployment of URNs remains elusive.
1.3.4 What is the outlook in the near to medium term?
There is a pressing need amongst the Internet community for a widely available, preferably decentralised, means of managing URNs and associating them with URLs. This is necessary to avoid the problems associated with temporary names (URLs), which are stored in directory services such as archie and would be helpful in providing support for rudimentary file caching on the Internet, as it provides a mechanism which is suited to the automatic selection of geographically ``close'' copies of a widely distributed resource.
This quotation is an extract from a message sent by Martin Hamilton to the uri@bunyip.com mailing list on 13 Jul 1993 (http://wwwwbs.cs.tu-berlin.de/html/urls/0205.html). As mentioned earlier, it was a further year before RFC 1737 - Functional requirements for URN was issued in December 1994, and a further 3 years before agreement was reached on the syntax and RFC 2141 URN Syntax. was issued in May 1997.
It is disappointing to note that in the four years since then, little progress has been made and the URN appears to be no closer to widespread deployment.
It is not easy to predict how the situation relating to URNs and URIs will develop. The length of time taken to arrive at an agreed syntax for the URN reflects the lack of consensus amongst some of the major players on the need for a URN at all. This lack of consensus is still present in the IETF and W3C community, as can be seen in the relevant discussion lists.
There is a fundamental philosophical difference between the two positions adopted. The push for a stronger identifier than the URL, as it is currently used, is largely coming from those in the digital library field who recognise that persistent naming is the cornerstone of the architecture of an open distributed library/archive system and from the rights management community who need an absolutely watertight persistent identifier system to support commercially oriented rights management systems. This position also is increasingly attracting the support of the community of xml developers who require persistent links for xml-schemas. To fulfil the needs of these groups (which include NLA), links must be stable over very long periods of time and be, as far as possible, location and system and protocol independent. Those who believe the URN development to be unnecessary and misguided argue that persistence is an administrative, social and management issue and that the URI as outlined in RFC 2396 will, if managed properly, meet all the needs of those advocating a URN standard.
There is a reluctance to accept that the concern of those who will be making huge investments in digital archives, whether of digitised content or born digital material, has a legitimate basis. To date there has been little concession that there are deficiencies arising from the current confusion and uncertainty over the URI/URL/URN status and supporting processes which weaken the case for the URI as a stable foundation on which to build a global digital library/archive. The URI/URL standards and registration processes need to be tightened up and clarified before it can fulfil the claims of its proponents.
For URNs to achieve widespread deployment, not only is consensus on functional requirements and syntax needed, but the ability to recognise and route URNs must be incorporated into standard Web browsers and a resolving infrastructure developed either by leveraging off the existing Domain Name System or by some other route. This is unlikely to happen in an environment where browser makers are uncertain what is accepted as a standard and developers of naming schemes are uncertain how to register their schemes.
The IETF (Internet Engineering Task Force) is responsible for the development of Internet protocols and standards. However in the area of WWW standards, W3C has the major role. It is responsible for Web resources and protocols for access and distribution, e.g. HTML specifications, PICS, RDF. The URI scheme is regarded as a Web specification and its extension or modification falls within the scope of W3C activities.
W3C has to date shown little interest in URN, or "name style" identifiers. In spite of this, the issue has continued to be debated. There is currently a W3C interest group looking at issues associated with URI schemes. The issues identified by this Group will be recommended as a workplan for a possible working group to work on and hopefully solve.
W3C has strongly resisted any move to develop a standard outside the framework of the URI. The position was stated early by James Miller in an article in D-Lib Magazine in November 1996, when he argued that all the technical infrastructure for the development of persistent identifiers was already available and it remains only for those interested to develop administrative and organisational infrastructure to realise their implementation. The continued adherence to this position is evident from current documentation on the W3C website and contributions to online discussions by W3C staff.
Whilst this position has some truth to it, it is also true that the support of W3C would make the task easier by encouraging the acceptance of name style identifiers by the major browser manufacturers. There is also as yet no standard resolution infrastructure for the resolution of URNs. The DDDS proposals mentioned earlier are still Internet drafts and will take some time to achieve the status of standards, let alone significant implementation.
In short, there is little prospect of an early solution to the resolution issue. All URN systems implemented in the near to medium future will require proxy servers to enable them to be used by standard web browsers and to route requests to the host server. This means that the identifiers will have to be encapsulated in a URL using the proxy server address.
1.4 Specific naming schemes
1.4.1 NBN (National Bibliography Number)
The NBN is a URN Namespace Identifier (NID) which was developed and registered by the National Library of Finland. It was subsequently considered and accepted in principle by the Persistent Identifier subcommittee of the CDNL (Committee of Directors of National Libraries) as a potential vehicle for a common URN based identifier for national libraries.
The NBN as originally conceived by the National Library of Finland was simply an electronic National Bibliography Number, and was essentially a running number preceded by a country code assigned to a single digital resource. The specification was subsequently further developed to accommodate a variety of needs and in the most recent registration proposal as an NBN namespace (January 2001) it was defined more broadly, although still in terms of a national bibliography.
Syntax of the NBN
The NBN consists of the Namespace Identifier (NID) nbn and a Namespace Specific String (NSS) The NSS commences with a prefix which identifies the origin of the number. The prefix may be a two character country code based on ISO 3166 or some other registered prefix. The prefix is followed by a delimiting character, usually a hyphen, and the string assigned by the national library. The resulting syntax is as follows:
urn:nbn:<ISO country code>-<assigned string>
e.g. urn:nbn:fi-20002561
urn:nbn:<registered prefix>-<assigned string>
e.g. urn:nbn:LCCN-9920567 (a Library of Congress Control number)
Resolution
There is no resolution system defined for the NBN. It is suggested in the Registration document that resolution would be through national bibliographic databases, or through web indexes or archives. In earlier drafts, it was stated that for global resolution, a NAPTR (Naming Authority PoinTeR) record would be created for each prefix. However neither NAPTR nor DDDS are mentioned in the current draft (issued January 2001).
As a URN, use of the NBN will be dependant on the deployment of URN resolution services, and until they are developed, will require http proxy servers to resolve.
1.4.2 PURLs
Background to PURL development
PURLs (Persistent URLs) were developed by OCLC primarily to reduce the maintenance burden of the URLs contained in records catalogued in Intercat, an Internet Cataloguing Project to investigate and establish cataloguing practice and standards for Internet resources. It therefore has its origin in library applications.
OCLC was an active participant in the IETF working groups on URNs and were fully aware of the issues being discussed and of how far the groups were from consensus on a standard solution. They therefore developed PURLs as an intermediate solution to address the lack of progress in Internet naming. OCLC planned at a later stage to automatically translate PURLs to the eventual URN form.
Resolution of PURLs
Functionally, a PURL is a URL. However, instead of addressing directly the location of an Internet resource, a PURL addresses an intermediate resolution service. This PURL Resolution Service associates the PURL with the actual URL and returns that URL to the client software. The client then completes the URL transaction to obtain the resource. The transaction is a standard Hypertext Transfer Protocol (HTTP) redirect.
PURLs creation and maintenance
PURLs are created and maintained using a standard Web browser to access a forms based service hosted by the relevant PURL server.
PURLs are not updated automatically when their associated URL changes. PURLs must be maintained by using the PURL Resolver's maintenance facility to update the location of the resource. Only authorised PURL maintainers can modify a PURL.
Availability of PURLs
PURLs use standard HTTP protocols to connect to PURL resolvers and standard HTTP redirects to return information to the requesting client. They do not require the acceptance of new protocols or any modifications to client software.
OCLC has made available the PURL source code to enable institutions to make use of the technology. Since the introduction of the PURL model and services, a number of institutions have installed their own PURL servers, including the NLA.
1.4.3 The Handle System
The Handle system is a distributed persistent naming system developed for digital library applications.
The handle system was developed by CNRI (Corporation for National Research Initiatives) and had its origin in a computer science technical reports project, NCSTRL (Networked Computer Science Technical Reports Library), funded by DARPA (Defense Advanced Research Projects Agency) in the US. Part of this project was to develop an architecture for the underlying infrastructure of an open distributed digital library. The high level architecture developed by the project is described in a seminal paper A framework for distributed digital object services May, 1995 by Robert Kahn and Robert Wilensky and subsequently by William Arms in an article Key Concepts in the Architecture of the Digital Library in D-Lib Magazine, July 1995.
In addition to its initial deployment in the NCSTRL project, the Handle system is also implemented by the Library of Congress in its National Digital Library Program, and in the Copyright Office (CORDS) where handles are assigned to deposited digital objects. The Handle system is also used by the DOI system for resolution of DOIs and in the US Defense Technical Information Center.
The system supplies a location independent identifier and a resolution system which can be used over the Internet.
Syntax of Handles
The handle itself is a persistent identifier consisting of two parts. The syntax is as follows:
<naming authority>/<name>
where the naming authority is an administrative unit authorised to create and maintain handles and the name of the resource is a string which must be unique to that authority but which has no prescribed syntax.
e.g. nla.pic/123456t
The naming authority may authorise sub authorities. The sub-authority identifier is separated from the name of the higher authority by a full stop, e.g.
10.1045
Where 10 is the identifier for the DOI system and thus identifies a DOI, and 1045 is the identifier for D-lib magazine.
loc.pnp
Where loc is the identifier for the Library of Congress and pnp identifies the Prints and Photographs Division
Structure of the Handle System
The handle system is more than a simple naming scheme, it is supported by a resolution system consisting of a distributed system of global, local, and caching servers.
The handle system provides all the capabilities listed in RFC 1737, "Functional Requirements for Uniform Resource Names described above (See Section 1.3.2).
The handle system consists of the following components:
Naming authorities are administrative units that are authorised to create and maintain handles. The name of a naming authority consists of one or more strings, separated by a full stop, as in the examples above.
The creation of naming authorities is delegated in a hierarchy. A Global Handle Registry run by CNRI registers the top level naming authorities, both to ensure the uniqueness of the names and to route requests for handle resolution. Each naming authority can then create sub-authorities, which in turn can have sub-authorities.
Handle servers store handles and provide a service to resolve them. Resolution of handles is carried out by handle servers, at the request of a client. There is a single Global Handle Server or Registry and many associated local handle servers maintained by naming authorities. The Global Handle Registry stores and resolves handles for all naming authorities and local handle servers and provides the client with information about which local handle server(s) can service a request. The Global Handle Server ensures uniqueness amongst handles stored at the global level.
Local handle servers are used by naming authorities to manage, store and resolve handles locally. These services resolve the requests and return the current address(es) or other information about the resource sought.
Caching servers associated with local servers allow frequently accessed handles to be resolved without need to request the address from the Global Registry.
Proxy servers allow Web browsers and other clients to resolve handles.
Availability of the Handle system
The Handle software is made publicly available and can be downloaded from the CNRI Handle site.
CNRI makes available local service software, client software and simple management tools, a caching handle server, tools for the creation and administration of handles and naming authorities, and a proxy server to enable Web clients to resolve handles. CNRI also provides a test server to allow trial resolution on non-critical data.
Use of handles can be through standard web browsers using a plug-in, or through unmodified web clients using proxy servers. Communication with the Handle System uses Handle System protocols. The resolution protocol has a corresponding API available as a library of C functions. This library, also known as the client library, has been used by CNRI in the creation of an http-to-handle proxy server, handle-aware extensions to the Netscape and Microsoft web browsers, and a handle caching server.
In the absence of ubiquitous support for the Handle protocols in standard browsers, both LC and DOI use proxy servers to enable standard browsers to access handles.
For a more detailed and technical description of the system see CNRI. The Handle System, Version 3.0 An Overview <http://www.handle.net/docs/overview.html>
1.4.4 Digital Object Identifier (DOI)
The DOI was developed by the AAP (American Association of Publishers) as a response to the growing concern over rights protection in open electronic networks. It was officially launched at the Frankfurt Book Fair in 1997 and it has recently been registered as an American National Standard ANSI/NISO Z39.84-2000. The DOI is now the responsibility of the IDF (International DOI Foundation), a not for profit foundation established by AAP to manage the DOI.
The intention was to develop an industry wide, standard identifier that would be assigned to a work, or manifestation of a work, at the time of creation. However, the DOI is intended to be more than a simple identifier. It was developed as a first step in the creation of an infrastructure to support rights management in the digital environment. The identifier is intended to support systems to control transactions, to provide a key for rights management systems and to facilitate communication between publishers and their clients.
In order to achieve this, the DOI has been developed as a complete system. It consists of three components:
- The syntax and assignment rules of the DOI identifier itself
- A resolution system
- A metadata structure to unambiguously identify the item represented by the DOI
DOI syntax
The DOI is composed of a Prefix and a Suffix. Within the prefix are the Directory Code <DIR> and the Registrant Code <REG>. The suffix is named the DOI Suffix String <DSS>.
The syntax of the DOI is a handle syntax:
<Directory code>.<Registry code>/<DOI Suffix String>
As the maintenance agency (or naming authority), the International DOI Foundation (IDF) assigns the Directory code and the Registry Code. The Directory Code is currently always 10 for a DOI, although additional codes may be assigned in the future, and the Registry code is the value of the code assigned by the IDF to a particular publisher, rights holder or registrant. The DOI Suffix String can be any string that meets the requirements of the registrant to whom the registry code has been assigned. It may include local identifiers or identifiers that are constructed according to other naming schemes, e.g. SICI, ISBN, PII. Examples taken from the NISO standard document indicate the diversity of numbering used in the local string.
DOI for the Authors Licensing and Collecting Societys Byline service:
10.054/1418EC1N2LE
DOI (incorporating a SICI) from an article in the Journal of the American Society for Information Science, published by John Wiley & Sons:
10.1002/(SICI)1097-4571(199806)49:8<693::AID-ASI4>3.0.CO;2-O
DOI for an article from JAMA, the Journal of the American Medical Association:
10.1001/PUBS.JAMA(278)3,JOC7055-ABST:
DOI for the article ABO Blood Group System from Encyclopedia of Immunology 2e
Online, published by Academic Press:
10.1006/rwei.1999.0001
DOI for the article: Digital Libraries and the Problem of Purpose published in D-Lib Magazine
10.1045/january2000-levy
The system derives much of its flexibility from the fact that it uses the DOI as a "dumb" number whose only function is to link items to a database entry. It can thus accommodate any other identifier system used by the participating publishers without the need to re-number existing items. The local string may itself have meaning (e.g. a SICI), but that is of no significance in the DOI.
Resolution of the DOI
Unlike many other identifier systems, the DOI is supported by a resolution system. It is an application of the Handle system developed by CNRI. (See above Section 1.4.3).
A record of the DOI together with the current location of the object is registered in the DOI system server. This server acts as a resolver to the objects themselves, which continue to reside on the publishers site or on a site licensed by the publisher. In the initial implementation, most DOIs resolve only to the publishers site, however with full deployment of the DOI system and the development of multiple resolution capabilities, and associated metadata, this will change. Changes of location are registered with the central server.
DOIs may be resolved through a native handle server for those with a handle enabled browser or through a proxy server which resolves to the handle server for those with standard browsers.
DOI Metadata
In order to achieve the functionality required by its developers, the DOI must be unambiguously associated with the item it represents and must be capable of being resolved to a number of different locations (multiple resolution). To facilitate automated selection and transactions, it must be possible to determine which work, version, or manifestation of an object is represented without recourse to inspection of the item. This can only be achieved successfully through carefully constructed metadata.
In addition, some basic metadata associated with the resolution process is necessary to support an intelligent selection between multiple locations for the same resource.
Thus, to support the development of the DOI in a move beyond its present state as a simple one on one resolution service, registration of a minimum set of standard metadata with the item will be required as an integral part of the assigning of a DOI.
For this purpose, the DOI has adopted the INDECS (Interoperability of Data in E-Commerce Systems) metadata set. The INDECS project, designed to provide a common metadata framework to support E-commerce in intellectual property, meshes neatly with the requirements of DOI. Eight mandatory elements are prescribed in the minimum, or kernel set of metadata, three of which (Genre, Type and origination) are to be derived from standard lists.
DOI governance and charging
The development of the DOI system has been the responsibility of the International DOI Foundation (IDF). The IDF is a not for profit organisation founded by the AAP, and its members are drawn from major publishers and software companies, as well as organisations which represent the interests of publishers and rights holders. E.g. International Publishers Association, International Association of Scientific, Technical and Medical Publishers, Authors Licensing and Collecting Society (ALCS), CSIRO Publishing, CAL, Copyright Clearance Centre, JISC, OCLC, and The Open University.
The DOI system is run on a cost recovery basis. It is an open system, free at the point of use and anyone may use a DOI to link to services. The DOI can be integrated into local environments and databases without charge. The cost of assigning a DOI is borne by the publisher or rights holder when it is assigned. It is intended primarily for use with intellectual property rights, but IDF policy does not rule out assigning DOIs to items in the public domain. The development costs are currently being borne by IDF membership fees.
The governance, administrative structure and charging mechanisms are in the process of change. The IDF is moving from an organisation supported by its members to one in which the day to day operation of the system is increasingly undertaken by a federation of registration agencies. Crossref was appointed the first Registration Agency in late 2000, and two others were in active negotiation in February 2001. It is expected that a number of additional DOI Registration agencies will be approved in 2001
Under these new arrangements, the IDF will remain a non-profit making maintenance agency, taking responsibility for the continued development of policies and standards. The IDF will also maintain the contractual relationships with Registration Agencies and with CNRI for the provision of Handle resolution services.
The role of the registration agencies will be to undertake day to day services to registrants, e.g. allocation of prefixes, registering DOIs and providing the infrastructure to allow registrants to declare and maintain metadata and state data (the current location(s) of the resource). Their responsibilities will also include quality assurance by ensuring that metadata is consistent and compliant and that state data is maintained by registrants and by providing adequate security for the registrants using the system. They are also expected to co-operate with IDF in the promotion and development of the DOI system.
The Registration Agencies are permitted to offer value-added services over and above the basic requirements (e.g. exploitation of registered metadata) and these services may be charged for, provided they do not conflict with the policies of the DOI as defined by the IDF.
Registration Agencies may be run for profit, but no mandatory model for the operation of a Registration Agency is laid down. They may charge for basic services (prefix allocation and DOIs registered) or cross subsidise these basic services from value added services.
Registration Agencies will have contractual arrangements with registrants and must provide consultative arrangements for addressing issues of common concern. Registrants may be affiliated to more than one Registration Agency.
IDF will remain a Registration Agency in the foreseeable future because it wishes to ensure that all markets are served.
DOI Fee Structure to December 2001
A Registration Agency must be a member of the IDF.
The annual membership of IDF is US$30,000. (No discretionary reductions are available for those subscribing in the Registration Agency category)
A franchise fee of 2 US cents per DOI registered is payable by the Registration Agency (US$20,000 per million DOI registered). A minimum franchise fee of US$20,000 is payable in first year regardless of how many DOIs are registered during that time. Payment of the franchise fee is to be made on a 6 monthly basis.
Future developments for DOI of interest to libraries and archives
The work done on the DOI is impressive. The intellectual and analytical skills brought to bear on the task have ensured that consideration of the issues have been wide ranging and thorough. This has been essential for this kind of operation. Because it is operating in a commercial environment, the structure of the system must be watertight and there is no room for the kind of ambiguity engendered by the use of URLs as identifiers.
DOI has been, as far as possible, designed to conform to existing standards to maximise interoperability. DOI metadata is based on the INDECS metadata set and will be expressed in RDF using XML; the DOI itself conforms to the syntax for URNs laid down in RFC 2141 URN Syntax and has been registered as a NISO standard.
Many of the considerations of persistence and identification of electronic resources facing DOI are those facing libraries and archives, even though the latter are not operating in the full commercial paradigm.
The IDFs plans for full deployment of the DOI system include the refinement and mandatory implementation of metadata standards and the development of multiple resolution capabilities and the ability to link the declared metadata to the DOI. These are considered essential prerequisites to a successful digital rights management infrastructure. (And, I would venture to say, a successful distributed archiving infrastructure.)
Points of concern expressed re DOIs
There has been considerable discussion and concern expressed in many quarters about the direct relationship of the DOI with rights management and copyright considerations. It is seen by many as satisfying the needs of major publishers while not necessarily meeting the needs of rights holders and those interested in fair use.
The majority of publishers are not in the same league as the major publishers and there are fears that the system may not be affordable for them. In addition to the charges that may be levied by Registration Agencies for the purchase of prefixes and assignment of identifiers, they may see participation and maintenance of the system, or the stringent requirements for the provision of metadata as a barrier.
Amongst libraries and academic institutions, there is the concern that because of the rights management aspect, full implementation and widespread use of the DOI may have the effect of making it easier to close off materials by making them unaffordable.
1.4.5 ARK (Archival Resource Key)
The most recently proposed identifier scheme is ARK (Archival Resource Key), which has been developed by John Kunze in his work for the US NLM (National Library of Medicine). The ARK proposal was issued as an Internet draft in March 2001.
The ARK is a scheme intended to facilitate the persistent naming and retrieval of information objects and is developed specifically to meet the needs of the custodians of archival digital objects. It is designed to be both location and protocol independent, while still retaining the ability to operate with todays protocols and tools, specifically with http, the DNS and current browsers. The total scheme comprises an identifier syntax and three services.
Further information can be found at http://www.ckm.ucsf.edu/people/jak/home/ark-01.txt
Syntax of the ARK
An ARK has four components with the following syntax:
<ark>:<NMAH>/<NAAN>/<Name>
Prefix ark denotes the scheme.
NMAH (Name Mapping Authority Hostport) is an optional and mutable component consisting of a hostname followed optionally by a colon and port number. The NMAH is a temporary address where ARK requests may be sent. It consists of an Internet hostname that has the same format and semantics as the domain name part of a URL. The significance of the NMAH is that it is not a part of the identifier and has no effect from the point of view of object identification. In other words, ARKs that differ only in the optional NMAH component are considered to identify the same object. For example, the following ARKs would identify the same resource:
ark:nla.gov.au/1703/1234567
ark:some.other.org/1703/1234567
ark:/1703/1234567
Because it is optional and changeable, over time the NAMH string may be replaced by a currently active service provider. Such a provider may be located using the NAAN by querying a global database to identify which NMAHs will service or resolve ARKs issued by that NAA. Meanwhile, in the current environment, a browser can create a valid http URI by substituting http for the ark prefix.
NAAN (Name Assigning Authority Number) is a registered number representing the authority that assigned the identifier.
The Name is assigned to the resource by the Name assigning Authority.
The NAAN and Name together form the immutable persistent identifier for the object.
ARK services
Like the DOI, metadata is a key component of the ARK proposal. Metadata provides the association between an ARK and the object it identifies.
Three ARK services are defined:
- request for the object itself (or a sensible substitute)
- request for the metadata describing the object
- request for a description of the commitment made by the Name Mapping Authority regarding the persistence of the object.
These services are defined initially to use the HTTP protocol, given that the www is the most widely deployed Internet delivery system. When the NMAH is specified, the "ark:" prefix may currently be replaced with "http://", to produce a valid URL that can gain access to ARK services using an unmodified Web client.
1.4.6 Other naming systems (SICI, BICI, ISSN, ISBN, etc.)
Existing naming schemes that are not designed specifically for use on the Internet are not examined here in detail. They are, if used in this context, most likely to be used in conjunction with database searching or another system that will provide the resolution. e.g. some publishers are using SICIs as the Namespace Specific String in the DOI. If these systems are registered as namespaces in their own right, as has been suggested in the case of ISSN and the ISDS International Centre, it may be possible to resolve them either via the registering agency, or by incorporation within another system.
Sources of detailed information on the standards are supplied in the Reading list, Appendix 5
| Return to Table of Contents | Proceed to Part 2 |
| About This Site | Copyright | Privacy | Accessibility | Site Map | Site Search | Content A-Z | Contact Us |