PURL (Persistent Uniform Resource Locators)
Implemented by the Online Computer Library Center (OCLC) in 1996, PURLs are actionable identifiers in their simplest form; a PURL points to a resolver which returns the current location of a resource in the form of an HTTP redirect. Originally intended to be a transitional phase awaiting URN development, PURLs were designed to be compatible with URN architecture. PURLs may be created using a public PURL server, or they may be created and maintained through a local resolver, which can be implemented using a free software package available from OCLC.
There is no added service cost for implementing and maintaining PURLs, and there is a relatively low technical barrier free of service dependencies, as PURLs are managed locally and built around widely used protocols. However, the technical and organizational infrastructure is also relatively rudimentary. As with all PIDs, once created PURLs are permanent. Bindings to the current location of the resource must be maintained by the PURL creator. If the binding is broken whether by actively deleting the resource or inadvertently changing its location, the PURL and its full history will still be available through the resolver service. In all cases, PURLs respond to queries by returning the appropriate HTTP response codes. PURL supports so-called partial redirection, which facilitates the management of hierarchical resources. Currently, the PURL service does not support access control, and thus PURLs are primarily useful for openly accessible web-based resources. PURLs are in relative wide use across the library sector, with servers currently hosted by, inter alia, OCLC, the National Library of Australia, the Danish Bibliographical Center, and the U.S. Government Printing Office.
Basic Form: [Protocol]/[Resolver Address]/[Local Name]
Sample: http://purl.abcd.org/ABC/DEF/200
The Handle System
Developed in 1994 by the Defense Advanced Research Projects Agency (DARPA) and the Corporation for National Research Initiatives (CNRI), which still administers the central site. Handle is a partially bundled service (including protocols, a namespace, and a software implementation) where the creation and maintenance of identifiers and bindings are 'outsourced' to a local repository hosting a Handle server. The central Handle service identifies the local server and directs the request to the server for resolution. Like PURLs, Handles are intended to complement URNs, such as DOI, though they can support identifiers of many types. Handle resolver software may be freely downloaded and locally utilized by any institution, though formal participation in the system comes with a small annual fee.
Handle is a moderately inexpensive and robust PID scheme and resolver solution, though administration is more complex than with PURLs. Unlike PURL, the Handle System is not based on HTTP and DNS protocols, though it can function within them. Instead, it maintains its own root server, the Global Handle Registry (GHR) to manage lower-level Naming Authorities. Handles can be resolved through the central resolver service or through HTTP protocols by prepending the hdl.handle.net prefix to the Handle. The system likewise allows granular control by local administrators through a database supporting additional permissions and bindings to multiple locations and other descriptive metadata. Among other things, this allows administrators to specify 'multiple resolutions,' such as various locations for one resource, (by appending the attribute '?locatt=' along with assigned criteria). This can support nuanced referencing of resource versions and variants. Today Handle provides the technology behind DOI implementation and resolution, allowing DOIs to function as indirect URLs. The Handle System is also used by digital repository software such as DSpace and CNRI's own Digital Object (DO) Repository.
The DOI (Digital Object Identifier) system was developed in 1997 by the Association of American Publishers and is now managed by the International DOI Foundation (IDF). DOI is a framework supporting structured identification, resolution, and other policies and tools. DOIs can currently be created, bound, and resolved using Handle technologies. DOI Registry Codes are assigned directly through licensed DOI Registration Authorities (RA), rather than by Handle's GHR, and local repositories must work through RAs to create, bind, and maintain their DOIs. Entry and maintenance costs depend solely on the policies of specific RAs but are often quite high.
DOIs are a fully articulated schema built over Handle services, but to take full advantage of DOIs potential requires a serious financial and professional commitment. Like Handles, DOIs exist independently of DNS and HTTP protocols, but can function within them by prepending the dx.doi.net proxy server or hdl.handle.net server to the DOI. The system is intended as a generic framework for naming entities of all types, though the focus of their model is on intellectual property related parties, resources, and events. DOI aims primarily at semantic interoperability. DOI binds PIDs to INDECs metadata and has developed Handle's support for linking resources into a fully articulated framework for expressing relationships. DOI likewise permits the definition of Application Profiles for specific communities working with similar data formats. DOIs are heavily supported by academic and scientific publishers, national libraries, and international organizations such as the Joint Information Systems Committee (JISC). The system is widely viewed as serving private sector interests. DOI is the first PID system to be officially supported by an ISO standard (ISO 26324:2012, Information and documentation – Digital object identifier system).
Basic Handle Form: [Handle Naming Authority]/[Local Name]
Sample PID: hdl:10345/3873
Sample PID URL: http://hdl.handle.net/10345/3873
Sample PID URL with location attribute: http://hdl.handle.net/10345/3873?locatt=id:1
Basic DOI Form: [Directory Code=”10”].[Registry code]/[Local Name]
Sample PID: doi:10.1006/jmbi.1998.2354
Sample PID URL: http://hdl.handle.net/10.1006/jmbi.1998.2354
Sample PID URL using DOI's proxy server: http://dx.doi.net/10.1006/jmbi.1998.2354
ARK (Archival Resource Key)
The ARK system was created in 2001 by the US National Library of Medicine and is currently maintained by the California Digital Library (CDL). Under ARK, institutions serve as Name Assigning Authorities (NAAN) or sub-authorities. Institutions must assign Name Mapping Authority Hostports (NMAH) where the 'mapping' of ARK names to actionable URLs and the resolution are provided. The purpose is to clearly separate the role of PID creators from that of the service providers that do the name mapping and resolution—though these are often the same institution. A NAAN may assign several NMAHs and a NMAH may serve several NAANs, but on all accounts the NMAH is considered a temporary role. In that sense, a particular ARK PID will only have a single NAAN but may have more than one NMAH, even at the same time. The CDL maintains a registry of all NAANs and their currently assigned NMAH service providers. There is no subscription fee or costs; an institution must only contact the CDL to receive a NAAN and simply generate ARKs using software to produce identifiers—open source solutions are also available.
Like PURLs, there is no added service cost for implementing and maintaining ARKs and no service dependencies. Like DOIs and Handles, ARKs theoretically exist independently of HTTP and DNS protocols, but unlike they former, currently they are only actionable within them. All resolution happens through the assigned NMAH. If an ARK-based URL fails to work because the NMAH is not current, then the current NMAH may be identified through CDL NAAN registry. In ARK, PIDs have fixed multiple resolutions, which can be accessed by appending suffixes, so-called inflections, to the root ARK. These include bindings to the resource location (using the simple PID form), to basic metadata about the resource (using the inflection '?') and to a commitment statement by the NMAH, including change history, future policies, and likelihood of persistence (using '??'). The commitment statement is central to the ARK concept, which rests on organizational commitment as much as identifier syntax or technical infrastructure. ARK's syntax supports optional qualifier strings to differentiate resource variants (using '.') or components (using '/'). ARKs can also be used for restricted resources. ARKs are now used by national repositories such as the Library of Congress, the Bibliotheque Nationale, the British Library, the Library and Archive of Canada, and the National Library of Hungary as well as other organizations such as the Digital Curation Center (DCC), the Internet Archive, and Google and several major American universities.
Basic Form: ark:/[NAAN]/[Local Name][Qualifier]
Sample PID: ark:/13030/tqb3kh8z
Sample PID with inflection to metadata: ark:/13030/tqb3kh8z?
Sample PID with component qualifier: ark:/13030/tqb3kh8z/chap3
Sample PID with variant qualifier: ark:/13030/tqb3kh8z/chap3/fig5.m
Sample PID with alternative variant qualifier: ark:/13030/tqb3kh8z/chap3/fig5.t
Basic PID URL Form: http://[NMAH/]ark:/[NAAN[/[Local Name][Qualifier]
Sample PID URL with given NMAH: http://bnf.fr/ark:/13030/tqb3kh8z
Sample PID URL with alterative NMAH: http://loc.gov/ark:/13030/tqb3kh8z
Related Resources
PURL (Persistent Uniform Resource Locators) (http://www.purl.org)
The Handle System (http://www.handle.net)
ARK (Archival Resource Key) (http://www.cdlib.org/inside/diglib/ark)