Persistent Identifiers for Digital Resources

Transcription

1 DRTC-HP International Workshop on Building Digital Libraries using DSpace 7 th 11 th March, 2005 DRTC, Bangalore Persistent Identifiers for Digital Resources A.R.D. Prasad ard@drtc.isibang.ac.in and Nabonita Guha guha@drtc.isibang.ac.in Documentation Research & Training Centre Indian Statistical Institute Bangalore Abstract The paper explores the possibilities of persistent naming (identification) system for digital resources. The paper also discusses the handle mechanisms of DSpace and EPrints software.

2 A.R.D. Prasad & Nabonita Guha 1. Introduction The most common way of discovering and locating objects in the world is by naming. Same pattern is being followed in libraries to identify and retrieve documents in traditional libraries. Call number/accession number is assigned to each document so that the document can be uniquely identified and retrieved as and when required. In similar fashion, digital resources should also be identified by unique identifiers in Web. For this purpose some mechanisms have been developed which assign persistent identifiers to digital objects irrespective of their location, just like ISBN for books/monographs. In the beginning, URLs were popularly used as the identifier to a digital resource. The URL may change due to several system-dependent factors like change in hardware reconfiguration, file system reorganization, or changes in organizational structure. As a result of all these changes the user gets the frustrating response from the browser Page not found. In such case the link of that resource given in other documents, or Webpages becomes redundant. To resolve the problem of identification and naming of digital objects, some mechanisms were developed to assign persistent identifiers to digital resources irrespective of their location. The major identifier schemes and persistent identifier mechanism used by digital library software are discussed in this paper. 2. What is Persistent Identifier? A persistent identifier is a name for a resource (digital) that will remain the same regardless of where the resource is located. Therefore links to the resource will continue to work even if it is moved [1]. This type of mechanism requires database that can keep track of the current location called resolver database. A resolver database maps the location of the resource and redirects the user to the current location. Redirecting work can be done without resolver database by using the standard redirect capabilities of the web server which can redirect the requests for resources using a persistent identifier to the actual location of the document or resource. But this method is hard to manage in a large repository. A resolver database can be a better option to map the name of a resource to the current location. Examples of resolver service PURL resolver, URN resolution service, etc. 3. Persistent Identifier Schemes The major persistent identifier schemes are: 3.1 Uniform Resource Name (URN): Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference [2]. URN identifiers are persistent and unique: The URN given to a document will never change, if the intellectual content remains the same. A "used" URN will never be given to any other document. [3] How URNs different from URLs A URN differs from a URL in that its primary purpose is persistent labeling of a resource with an identifier. That identifier is drawn from one of a set of defined namespaces (Namespace is a way of defining each element type and attribute name uniquely), each of which has its own set name structure and assignment procedures [4] General Principles [5] Naming schemes and resolution systems. The framework distinguishes between naming schemes and resolution systems. A naming scheme is a procedure for creating and assigning unique URNs that conform to a specified syntax. A resolution system is a network-accessible service that stores URNs and resolves them. Independence between naming schemes and resolution systems. A naming scheme is not tied to a specific resolution system. Any resolution system is potentially capable of resolving a URN from any given name scheme. 2

3 Persistent Identifiers URN registries. Since naming schemes and resolution systems are conceptually independent, mechanisms must be created so that the user of a URN can discover what resolution systems are able to resolve the URN. This is called a URN registry or simply a registry URN Syntax: URN is like an umbrella system which can accommodate in itself all existing resource identification systems. This has been made possible by URN syntax (string) proposed by URN Working Group in 1999 which consists of three parts: URN, NID (Namespace Identifier), and NSS (Namespace Specific String). [6] URN:NID:NSS Examples: urn:isbn: x urn:hdl:1849/171 urn:inet:drtc.isibang.ac.in urn:path:home/desktop/dspace.doc Namespace identifier (NID) code indicates the identification system being used for URN the system used as an URN and facilitates the interpretation of NSS. For instance, "ISBN" in NID indicates that the identification system is ISBN of a book. In the above examples hdl (NID for Handles), inet (NID for Website), and path (NID for resource location path) are namespace identifiers (NIDs) delivered by Internet Assigned Names Authority, responsible for assigning namespace identifiers. Namespace specific string (NSS) contains the actual identifier of the digital resource, such as X How the URN Mechanism Works URNs are a part of large Internet Information Architecture containing URCs (Uniform Resource Characteristics includes meta-information of the resource) and URLs (Uniform Resource Locators identifies and locates resources). When a URN is submitted at the browser s address bar, the global URN resolution service translates the URN either into URL or provides the metadata of the resource or leads to the actual document How to put URN in a digital resource When a resource has URN, it can be placed in the meta tags of HTML. It will help the search engines to index the URN. It can be best utilized if it can be put along with Dublin Core Element Set (DC Identifier tag). For example: <METANAME="DC.Identifier"SCHEME="URN"CONTENT=URN:ISBN:" X 3.2 Internationalized Resource Identifier (IRI): [7] The concept of IRI has been developed with an attempt to internationalize URIs. So far URIs contain limited US-ACSII characters (English like characters) (about 60) along with some special characters. But the infrastructure for the appropriate handling of characters from local scripts is now widely deployed in local versions of operating system and application software. Also, there are increasing number of protocols and formats that can carry a wide range of characters. Therefore, URI syntax has been extended by including UTF-8 characters to it, which includes the characters other than English. An IRI is a sequence of characters from the Universal Character Set (ISO-10646). There is a mapping from IRIs to URIs, which means that IRIs can be used instead of URIs where appropriate to identify resources. This doesn t mean that URIs will become obsolete. IRIs is merely complement URIs Factors Limiting the Use of IRIs 3

4 A.R.D. Prasad & Nabonita Guha IRI at present a new concept and subject to change that there are very few instances of its application. Software developers are also waiting for the mechanism to stabilise before investing time to support IRIs. While placing IRIs in documents or web pages presents no key issues, IRIs are not a practical replacement for URIs. Protocols that require URIs currently do not accept IRIs, because they cannot distinguish diacritic marks (such as Māori macrons) with characters from those without them. 3.3 Persistent Uniform Resource Locator (PURL) [8] PURL is a general naming and resolution service developed and implemented by Online Computer Library Center, Inc. It has been developed as an interim service to resolve the problem of broken links or inconsistent links, until a global URN framework is established. PURLs are unique identifiers assigned to digital resource; no two resources can be assigned same PURL. PURLs looks like URLs but instead of directing the client to the resource, it goes to the PURL resolver where from the actual URL is supplied, which ultimately brings out the requested resource (Fig.1). C L I E N T PURL URL URL Resource PURL Server Resource Server Resolver associates PURL with unique URL; maintenance utilities facilitate creation of PURLs and modification of associated URLs Fig. 1 PURL Resolution service The PURL looks like URL, consists of three parts: protocol, resolver address and user assigned name. Protocol: to access the PURL resolver. Resolver address: the IP address or domain name of the PURL resolver. Name: Name of the resource assigned by the user. PURL: Protocol Resolver Address Name URL: Whenever the location of the resource changes, the new location needs to be updated in the PURL resolver database. 3.4 Digital Object Identifier (DOI) [9] The Digital Object Identifier (DOI) is a system for identifying content objects in the digital environment. DOIs are names assigned to any entity for use on digital networks. The DOI system provides a framework for persistent identification, managing intellectual content, 4

5 Persistent Identifiers managing metadata, linking customers with content suppliers, facilitating electronic commerce, and enabling automated management of media. DOIs can be used for any form of management of any data, whether commercial or non-commercial Features of DOI: [10] It is an open system based on nonproprietary standards. Some notable features are: A persistent identifier: identifies an object persistently irrespective of changes in location, ownership, description methods, and other changeable attributes. An actionable identifier: Like URLs DOIs are also actionable entities, which are used to locate the resource. An interoperable identifier: DOI system has been designed to be interoperable with past, present and future technologies. Interoperability enables rich interlinking with related content, so as to increase the content's usefulness and visibility DOI Syntax [10] DOI identifier has been made like a container which can accommodate already existing identifiers. In that respect its syntax is similar to that of URN s. DOI identifier consists of two parts: prefix and suffix. Example: / ISO-DOI /ISBN The part following / (i.e. suffix) denotes the existing identifier and the part succeeding (i.e. prefix) denotes the unique identifier of the object DOI Resolution [10] Resolution is the process of submitting an identifier [of an entity] to a network service and receiving in return one or more pieces of current information related to the identified entity. In the case of the Domain Name System (DNS), as an example, the resolution is from domain name, e.g., to a single IP address, e.g., , which is then used to communicate with that Internet host. Single Resolution: Each DOI has a single URL to which it could resolve. This allows the location of an entity to be changed while maintaining the name of the entity as an actionable identifier (Fig. 2). Fig.2 Single Resolution Multiple Resolution: Multiple resolution, allows one entity to be resolved to multiple other entities; it can be used to embody e.g. a parent-children relationship, or any other relationship (Fig. 3). 5

6 A.R.D. Prasad & Nabonita Guha Fig. 3 Multiple Resolution 3.5 The ARK (Archival Resource Key) Persistent Identifier Scheme [11] The ARK (Archival Resource Key) naming scheme is designed to facilitate the highquality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support persistence Definition of Identifier [12] In most generic way, an identifier is an association between a string (a sequence of characters) and an information resource. That association is made manifest by a record (in the case of ARK service, a METS record) that binds the identifier string to a set of identifying resource characteristics. Each ARK links end-users to three things: Digital object metadata Digital object content files A commitment statement made by the California Digital Library concerning the digital object ARK Anatomy An ARK has five components: ark:/naan/name[qualifier] NMAH Name Mapping Authority Hostport ark Label NAAN Name Assigning Authority Number The assigned name Diagrammatical Example (Replaceable) ARK Label Name Name Mapping Authority Hostport (NMAH) Name Assigning Authority Number Fig. 4 ARK Anatomy (Syntax) An ARK is represented by a sequence of characters (a string) that contains the label, "ark:", optionally preceded by the beginning part of a URL. The URL, or the "Name Mapping 6

7 Persistent Identifiers Authority Hostport" (NMAH), is mutable and replaceable. The immutable, globally unique identifier follows the "ark:" label. This includes the "Name Assigning Authority Number" (NAAN) for the CDL, followed by the name that CDL assigned. [12] Entering the ARK in a web browser produces an object. Entering the ARK followed by a single question mark ("?") produces the metadata only. Entering the ARK followed by a double question mark ("??") produces a CDL commitment statement. At this time the CDL commitment statement is in development and under final review. 3.6 Corporation for National Research Initiatives (CNRI) Handle System Handle system was developed by Corporation for National Research Initiatives (CNRI) as part of the Computer Science Technical Reports (CSTR) project, funded by Defense Advanced Projects Agency (DARPA). Here the word handle is used as the unique identifier assigned to a digital resource (nothing to do with actual handle like objects). The Handle System is a distributed information system designed to provide an efficient, extensible, and secured global name service for use on networks such as the Internet. The Handle System includes an open protocol, a namespace, and a reference implementation of the protocol. The protocol enables a distributed computer system to store names, or handles, of digital resources and resolve those handles into the information necessary to locate, access, and otherwise make use of the resources [13]. Like other persistent identifier schemes discussed earlier, handle systems are developed with more or less same objective of overcoming the limitations of traditional URL pattern of digital object identification system Handle Syntax Every handle consists of two parts: its naming authority, otherwise known as its prefix, and a unique local name under the naming authority, otherwise known as its suffix: Example: hdl:1849/171 Fig. 5 Handle Namespace [14] In the example 1849 is the naming authority assigned by handle system to DRTC Digital Library, followed by the unique local name assigned to an article in the repository. The naming authority identifies the administrative unit of creation of the associated handles. DRTC is the administrative unit here, having globally unique identifier (1849) within the Handle System Handle System Architecture [13] Handle system architecture is a hierarchical model, comprises of two levels: Global Handle Registry (GHR) and Local Handle Registry (LHR). Global Handle Registry (Top Level): The Global Handle Registry can be used to manage any handle namespace. It is unique among handle services only in that it provides the service used to manage naming authorities, all of which are managed as handles. The naming authority handle provides information that clients can use to access and utilize the local handle service for handles under the naming authority. Local handle Registry (Lower Level): Local Handle Services are intended to be hosted by organizations with administrative responsibility for handles under certain naming authorities. A Local Handle Service may be responsible for any number of local handle 7

8 A.R.D. Prasad & Nabonita Guha namespaces, each identified by a unique naming authority. The Local Handle Service and its responsible set of local handle namespaces must be registered with the Global Handle Registry Functioning of Handle System [14] (Fig. 6) Fig. 6: Handle System Architecture [14] 1. A client such as a web browser encounters a handle, e.g., /456, on the Internet or an individual intranet, typically as a hyperlink or other kind of reference. The client sends the handle to the Handle System for resolution. This can be done directly by a client which understands the handle resolution protocol natively or through a proxy server. 2. The Handle System consists of a collection of handle services, as described above. One service, the Global Handle Registry, is responsible for knowing the locations and name space responsibilities of all of the public Local Services. Each of these Local Services know how to access the Global Handle Registry. This allows a resolution query to enter the Handle System at any point and to be routed to the specific service and server which knows the answer. 3 & 4. Each handle can be associated with one or more pieces of typed data. In this example, the handle /456 is associated with, and so resolves to, both a URL and a new protocol called RAP. This is the information which is returned to the client. Note that it would also be possible to associate multiple instances of the same data type, e.g., multiple URLs, with a single handle. The Handle System is a pure resolution system and carries no assumptions on what the client will or will not do with the resolution information, thus maximizing the flexibility of applications which use the Handle System as an infrastructure for naming. In the example shown, the client can presumably use either protocol to locate and retrieve the item, although again this is up to the client. To improve resolution performance, any client may select to cache the service information returned from the global service, and/or the resolution result from any local service. A separate handle caching server, either stand-alone or as a piece of a general caching mechanism, may also be used to provide shared caching within a local community. Given a cached resolution result, subsequent queries of the same handle may be answered locally without contacting any handle service. Given cached service information, clients can send their requests directly to the responsible local service without contacting global. 8

9 Persistent Identifiers Implementation of Handle System in DSpace [15] To resolve the problem of broken links and to provide the researchers a better facility of referencing/citing digital resources, DSpace made the provision to assign persistent identifiers to the same. The software uses CNRI Handle system for creating these identifiers. DSpace uses Handles primarily as a means of assigning globally unique identifiers to objects. Each site running DSpace needs to obtain a Handle 'prefix' from CNRI, so that if identifiers are created with that prefix, they won't clash with identifiers created elsewhere. Presently, Handles are assigned to communities, collections, and items. Bundles and bitstreams are not assigned Handles, since over time, the way in which an item is encoded as bits may change, in order to allow access with future technologies and devices. Older versions may be moved to off-line storage as a new standard becomes de facto. Since it's usually the item that is being preserved, rather than the particular bit encoding, it only makes sense to persistently identify and allow access to the item, and allow users to access the appropriate bit encoding from there. Of course, it may be that a particular bit encoding of a file is explicitly being preserved; in this case, the bitstream could be the only one in the item, and the item's Handle would then essentially refer just to that bitstream. The same bitstream can also be included in other items, and thus would be citable as part of a greater item, or individually. The Handle system also features a global resolution infrastructure; that is, an end-user can enter a Handle into any service (e.g. Web page) that can resolve Handles, and the end-user will be directed to the object (in the case of DSpace, community, collection or item) identified by that Handle. In order to take advantage of this feature of the Handle system, a DSpace site runs a 'Handle server' that accepts and resolves incoming resolution requests. All the code for this is included in the DSpace source code bundle. 3.7 OAI Identifier Format The OAI identifier format [16] is intended to provide persistent resource identifiers for items in repositories that implement OAI-PMH. Being OAI-PMH compliant EPrints software uses OAI Identifier format to assign persistent identifiers to the digital resources in the repository What are OAI Identifiers? oai-identifiers are Uniform Resource Names (URNs) (RFC 1737 [17] ). As oai-identifiers are an implementation of URN, they can be used only to identify a resource and NOT to locate the resource [16]. Note that here the resource is the metadata (the items) and not the digital object that the metadata describes Syntax of OAI Identifiers Syntax of OAI Identifiers: The oai-identifier syntax follows the generic URI syntax i.e. <scheme>:<scheme-specific-part>, defined in RFC 2396 [4]. Syntax: oai-identifier = scheme ":" namespace-identifier ":" local-identifier scheme = "oai" namespace-identifier = domainname-word "." domainname 9

10 A.R.D. Prasad & Nabonita Guha local-identifier = 1*uric Let us take an example record from the Digital Library for Information Science and Technology (DLIST) archive. It uses the EPrints software for its archive. A typical oai identifier in DLIst would looks like this: oai:dlist.oai2:32 where, oai = scheme DLIST.OAI2 = domainname-word.domainname = namespace-identifier 32 = local-identifier Note: Namespace Identifiers: Organizations must choose namespace-identifier values which correspond to a domain-name that they have registered, and are committed to maintaining Encoding Requirement for OAI Identifiers oai-identifiers are not designed for human use, they are designed to be used only with the OAI-PMH. As such, presentation in text, electronic mail etc. is not important. This makes the encoding requirements considerably simpler than those described in RFC1737: Single encoding: there should be just one way to write an oai-identifier. Simple comparison: there should be a trivial and local algorithm to compare two oai-identifiers. Transport friendliness: oai-identifiers should be able to be transported unmodified over common Internet protocols (e.g. HTTP) and using common encoding standards (e.g. XML, RDF). Machine consumption: oai-identifiers should be easy to parse. Ease of use: oai-identifiers should be short so that transmitting them and managing them within computer programs is convenient. 4. References 1. Persistent Identifier scheme for digital collections at the National Library of Australia L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. (June 1999). URN Namespace Definition Mechanisms. ftp://ftp.isi.edu/in-notes/rfc2611.txt 3. URN creation tool, Nordic Metadata Project. Help: URN User Guide. Version 1.0. ( ) T. Berners-Lee, et al. Uniform Resource Identifiers (URI): Generic Syntax. Network Working Group RFC2396. August Uniform Resource Names: a progress report. D-Lib Magazine. February Juha Hakala. Uniform Resource Names. Tietolinja News 1/ Duerst, Martin & Suignard, Michel Internationalized Resource Identifiers (IRI), draft-duerst-iri-01. Network Working Group, Internet Draft, July Stuart Weibel, Erik Jul, Keith Shafer. PURLs: Persistent Uniform Resource Locators The International DOI Foundation. The Digital Object Identifier System. 10

11 Persistent Identifiers 10. DOI Handbook J. Kunze, R. P. C. Rodgers. The ARK Persistent Identifier Scheme. Internet-Draft: draft-kunze-ark-09.txt. 19 February Archival Resource Key (ARK) S. Sun, L. Lannom, B. Boesch. Handle System Overview. Network Working Group, Request for Comments: November Laurence Lannom. Handle System Overview. ICSTO Forum. No. 30, April DSpace Documentation: Functional Overview. Version (Stable) 16. Specification and XML Schema for the OAI Identifier Format Protocol Version 2.0 of K. Sollins, L. Masinter. Functional Requirements for Uniform Resource Names. Network Working Group, Request for Comments: December