Handle System

Last updated

The Handle System is the Corporation for National Research Initiatives's proprietary registry assigning persistent identifiers, or handles, to information resources, and for resolving "those handles into the information necessary to locate, access, and otherwise make use of the resources". [1]

Contents

As with handles used elsewhere in computing, Handle System handles are opaque, and encode no information about the underlying resource, being bound only to metadata regarding the resource. Consequently, the handles are not rendered invalid by changes to the metadata.

The system was developed by Bob Kahn at the Corporation for National Research Initiatives (CNRI). The original work was funded by the Defense Advanced Research Projects Agency (DARPA) between 1992 and 1996, as part of a wider framework for distributed digital object services, [2] and was thus contemporaneous with the early deployment of the World Wide Web, with similar goals.

The Handle System was first implemented in autumn 1994, and was administered and operated by CNRI until December 2015, when a new "multi-primary administrator" (MPA) mode of operation was introduced. The DONA Foundation [3] now administers the system's Global Handle Registry and accredits MPAs, including CNRI and the International DOI Foundation. [4] The system currently provides the underlying infrastructure for such handle-based systems as Digital Object Identifiers and DSpace, which are mainly used to provide access to scholarly, professional and government documents and other information resources.

CNRI provides specifications and the source code for reference implementations for the servers and protocols used in the system under a royalty-free "Public License", similar to an open source license. [5]

Thousands of handle services are currently running. Over 1000 of these are at universities and libraries, but they are also in operation at national laboratories, research groups, government agencies, and commercial enterprises, receiving over 200 million resolution requests per month.[ citation needed ]

Specifications

The Handle System is defined in informational RFCs 3650, [1] 3651 [6] and 3652 [7] of the Internet Engineering Task Force (IETF); it includes an open set of protocols, a namespace, and a reference implementation of the protocols. Documentation, software, and related information is provided by CNRI on a dedicated website [8]

Handles consist of a prefix which identifies a "naming authority" and a suffix which gives the "local name" of a resource. Similar to domain names, prefixes are issued to naming authorities by one of the "multi-primary administrators" of the system upon payment of a fee, which must be renewed annually. A naming authority may create any number of handles, with unique "local names", within their assigned prefixes. An example of a handle is:

In the first example, which is the handle for the HANDLE.NET software license, 20.1000 is the prefix assigned to the naming authority (in this case, Handle.net itself) and 100 is the local name within that namespace. The local name may consist of any characters from the Unicode UCS-2 character set. The prefix also consists of any UCS-2 characters, other than "/". The prefixes consist of one or more naming authority segments, separated by periods, representing a hierarchy of naming authorities. Thus, in the example 20 is the naming authority prefix for CNRI, while 1000 designates a subordinate naming authority within the 20 prefix. Other examples of top-level prefixes for the federated naming authorities of the DONA Foundation are 10 for DOI handles; 11 for handles assigned by the ITU; 21 for handles issued by the German Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG), the scientific computing center of the University of Göttingen; and 86 for the Coalition of Handle Services – China. Older "legacy" prefixes issued by CNRI before the "multi-primary administrator" (MPA) structure was instituted are typically four of five digits, as in the second example above, a handle administered by the University of Leicester. All prefixes must be registered in the Global Handle Registry through an DONA Foundation approved registrar, normally for a fee.

As with other uses of handles in computing, the handle is opaque; that is, it encodes no information about the underlying resource and provides only the means to retrieve metadata about the resource.

This may be contrasted with a Uniform Resource Locator (URL), which may encode within the identifier such attributes of the resource as the protocol to be used to access the server holding the resource, the server host name and port number, and perhaps even location specifics such as the name of a file in the server file system containing the resource. In the Handle System, these specifics are not encoded in the handle, but are found in the metadata to which the handle is bound.

The metadata may include many attributes of the information resource, such as its locations, the forms in which it is available, the types of access (e.g. "free" versus "paid") offered, and to whom. The processing of the metadata to determine how and where the resource should be accessed, and the provision of the resource to the user, are performed in a separate step, called "resolution", using a Resolver, a server which may be different from the ones involved in exchanging the handle for the metadata. Unlike URLs, which may become invalid if the metadata embedded within them becomes invalid, handles do not become invalid and do not need to change when locations or other metadata attributes change. This helps to prevent link rot, as changes in the information resource (such as location) need only be reflected in changes to the metadata, rather than in changes in every reference to the resource.

Each handle may have its own administrator and administration of the handles can be done in a distributed environment, similar to DNS domain names. The name-to-value bindings may also be secured, both via signatures to verify the data and via challenge response to verify the transmission of the data, allowing handles to be used in trust management applications.

It is possible for the same underlying information resource to be associated with multiple handles, as when two university libraries generate handles (and therefore possibly different sets of metadata) for the same book.

The Handle System is compatible with the Domain Name System (DNS), but does not require it, unlike persistent identifiers such as PURLs or ARKs, which are similar to handles, but which utilise domain names. However, unlike these domain-name based approaches, handles do require a separate prefix registration process and handle servers separate from the domain name servers.

Handles can be used natively, or expressed as Uniform Resource Identifiers (URIs) through a namespace within the info URI scheme; [9] [10] for example, 20.1000/100 may be written as the URI, info:hdl/20.1000/100. Some Handle System namespaces, such as Digital Object Identifiers, are "info:" URI namespaces in their own right; for example, info:doi/10.1000/182 is another way of writing the handle for the current revision of the DOI Handbook [11] as a URI.

Some Handle System namespaces define special presentation rules. For example, Digital Object Identifiers, which represent a high percentage of the extant handles, are usually presented with a "doi:" prefix: doi:10.1000/182.

Any Handle may be expressed as a Uniform Resource Locator (URL) through the use of the generic HTTP proxy server,: [12]

Some Handle-based systems offer an HTTP proxy server that is intended for use with their own system such as:

Implementation

Implementation of the Handle System consists of Local Handle Services, each of which is made up of one or more sites that provide the servers that store specific handles. The Global Handle Registry is a unique Local Handle Service which stores information on the prefixes (also known as naming authorities) within the Handle System and can be queried to find out where specific handles are stored on other Local Handle Services within this distributed system.

The Handle System website provides a series of implementation tools, notably the HANDLE.NET Software [13] and HANDLE.NET Client Libraries. [14] Handle clients can be embedded in end user software (e.g., a web browser) or in server software (e.g., a web server) and extensions are already available for Adobe Acrobat [15] and Firefox. [16]

Handle client software libraries are available in both C and Java. Some applications have developed specific add-on tools, e.g., for the DOI System. [17]

The interoperable network of distributed handle resolver servers (also known as the Proxy Server System) are linked through a Global Resolver (which is one logical entity though physically decentralised and mirrored). Users of Handle System technology obtain a handle prefix created in the Global Handle Registry. The Global Handle Registry maintains and resolves the prefixes of locally maintained handle services. Any local handle service can, therefore, resolve any handle through the Global Resolver.

Handles (identifiers) are passed by a client, as a query of the naming authority/prefix, to the Handle System's Global Handle Registry (GHR). The GHR responds by sending the client the location information for the relevant Local Handle Service (which may consist of multiple servers in multiple sites); a query is then sent to the relevant server within the Local Handle Service. The Local Handle Service returns the information needed to acquire the resource, e.g., a URL which can then be turned into an HTTP re-direct. (Note: if the client already has information on the appropriate LHS to query, the initial query to GHR is omitted)

Though the original model from which the Handle System derives dealt with management of digital objects, the Handle System does not mandate any particular model of relationships between the identified entities, nor is it limited to identifying only digital objects: non-digital entities may be represented as a corresponding digital object for the purposes of digital object management. Some care is needed in the definition of such objects and how they relate to non-digital entities; there are established models that can aid in such definitions e.g., Functional Requirements for Bibliographic Records (FRBR), CIDOC CRM, and indecs content model. Some applications have found it helpful to marry such a framework to the handle application: for example, the Advanced Distributed Learning (ADL) Initiative [18] brings together Handle System application with existing standards for distributed learning content, using a Shareable Content Object Reference Model (SCORM), [19] and the Digital Object Identifier (DOI) system implementation of the Handle System has adopted it together with the indecs framework to deal with semantic interoperability.

The Handle System also makes explicit the importance of organizational commitment to a persistent identifier scheme, but does not mandate one model for ensuring such commitment. Individual applications may choose to establish their own sets of rules and social infrastructure to ensure persistence (e.g., when used in the DSpace application, and the DOI application). [20]

Design principles

The Handle system is designed to meet the following requirements to contribute to persistence [21]

The identifier string:

The identifier resolution mechanism:

Applications

Among the objects that are currently identified by handles are journal articles, technical reports, books, theses and dissertations, government documents, metadata, distributed learning content, and data sets. Handles are being used in digital watermarking applications, GRID applications, repositories, and more. Although individual users may download and use the HANDLE.NET software independently, many users have found it beneficial to collaborate in developing applications in a federation, using common policy or additional technology to provide shared services. As one of the first persistent identifier schemes, the Handle System has been widely adopted by public and private institutions and proven over several years. (See Paradigm, Persistent identifiers.) [22]

Handle System applications may use handles as simple persistent identifiers (as most commonly used, to resolve to the current URL of an object), or may choose to take advantage of other features. Its support for the simultaneous return as output of multiple pieces of current information related to the object, in defined data structures, enables priorities to be established for the order in which the multiple resolutions will be used. Handles can, therefore, resolve to different digital versions of the same content, to mirror sites, or to different business models (pay vs. free, secure vs. open, public vs. private). They can also resolve to different digital versions of differing content, such as a mix of objects required for a distance-learning course.

There are thousands of handle services running today, located in 71 countries, on 6 continents; over 1000 of them run at universities and libraries. Handle services are being run by user federations, national laboratories, universities, computing centers, libraries (national and local), government agencies, contractors, corporations, and research groups. Major publishers use the Handle System for persistent identification of commercially traded and Open Access content through its implementation with the Digital Object Identifier (DOI) system.

The number of prefixes, which allow users to assign handles, is growing and stands at over 12,000 as of early 2014. There are six top-level Global Handle Registry servers that receive (on average) 68 million resolution requests per month. Proxy servers known to CNRI, passing requests to the system on the Web, receive (on average) 200 million resolution requests per month. (Statistics from Handle Quick Facts.)

In 2010, CNRI and ITU (International Telecommunication Union) entered into an agreement to collaborate on use of the Handle System (and the Digital Object Architecture more generally) and are working on the specific details of that collaboration; in April 2009 ITU listed the Handle System as an "emerging trend". [23]

Licences and use policy

Handle System, HANDLE.NET and Global Handle Registry are trademarks of the Corporation for National Research Initiatives (CNRI), a non-profit research and development corporation in the US. The Handle System is the subject of patents by CNRI, which licenses its Handle System technology through a public license, [24] similar to an open source license, in order to enable broader use of the technology. Handle System infrastructure is supported by prefix registration and service fees, with the majority coming from single prefix holders. The largest current single contributor is the International DOI Foundation. The Public License allows commercial and non-commercial use at low cost of both its patented technology and the reference implementation of the software, and allows the software to be freely embedded in other systems and products. A Service Agreement [5] is also available for users who intend to provide identifier and/or resolution services using the Handle System technology under the Handle System public license.

The Handle System represents several components of a long-term digital object architecture. In January 2010 CNRI released its general-purpose Digital Object Repository software, [25] another major component of this architecture. More information [26] about the release, including protocol specification, source code and ready-to-use system, clients and utilities, is available. [27] [28]

See also

Related Research Articles

<span class="mw-page-title-main">Dublin Core</span> Standardized set of metadata elements

The Dublin Core, also known as the Dublin Core Metadata Element Set (DCMES), is a set of fifteen main metadata items for describing digital or physical resources. The Dublin Core Metadata Initiative (DCMI) is responsible for formulating the Dublin Core; DCMI is a project of the Association for Information Science and Technology (ASIS&T), a non-profit organization.

A Uniform Resource Identifier (URI) is a unique sequence of characters that identifies an abstract or physical resource, such as resources on a webpage, mail address, phone number, books, real-world objects such as people and places, concepts. URIs are used to identify anything described using the Resource Description Framework (RDF), for example, concepts that are part of an ontology defined using the Web Ontology Language (OWL), and people who are described using the Friend of a Friend vocabulary would each have an individual URI.

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable. URNs cannot be used to directly locate an item and need not be resolvable, as they are simply templates that another parser may use to find an item.

<span class="mw-page-title-main">Digital object identifier</span> ISO standard unique string identifier for a digital object

A digital object identifier (DOI) is a persistent identifier or handle used to uniquely identify various objects, standardized by the International Organization for Standardization (ISO). DOIs are an implementation of the Handle System; they also fit within the URI system. They are widely used to identify academic, professional, and government information, such as journal articles, research reports, data sets, and official publications.

REST is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave. The REST architectural style emphasises uniform interfaces, independent deployment of components, the scalability of interactions between them, and creating a layered architecture to promote caching to reduce user-perceived latency, enforce security, and encapsulate legacy systems.

A persistent uniform resource locator (PURL) is a uniform resource locator (URL) that is used to redirect to the location of the requested web resource. PURLs redirect HTTP clients using HTTP status codes.

XML namespaces are used for providing uniquely named elements and attributes in an XML document. They are defined in a W3C recommendation. An XML instance may contain element or attribute names from more than one XML vocabulary. If each vocabulary is given a namespace, the ambiguity between identically named elements or attributes can be resolved.

The Corporation for National Research Initiatives (CNRI), based in Reston, Virginia, is a non-profit organization founded in 1986 by Robert E. Kahn as an "activities center around strategic development of network-based information technologies", including the National Information Infrastructure (NII) in the United States.

PRONOM is a web-based technical registry to support digital preservation services, developed by The National Archives of the United Kingdom. PRONOM was the first and remains, to date, the only operational public file format registry in the world, although the "Magic File" repository of the File Command has served this role in a less formal capacity for two decades. Other projects to develop technical registries, including the UK Digital Curation Centre's Representation Information Registry, and the Global Digital Format Registry project at Harvard University, are now in progress.

<span class="mw-page-title-main">Minimum information required in the annotation of models</span>

MIRIAM is a community-level effort to standardize the annotation and curation processes of quantitative models of biological systems. It consists of a set of guidelines suitable for use with any structured format, allowing different groups to collaborate and share resulting models. Adherence to these guidelines also facilitates the sharing of software and service infrastructures built upon modeling activities.

<span class="mw-page-title-main">Object Manager (Windows)</span>

Object Manager is a subsystem implemented as part of the Windows Executive which manages Windows resources. Resources, which are surfaced as logical objects, each reside in a namespace for categorization. Resources can be physical devices, files or folders on volumes, Registry entries or even running processes. All objects representing resources have an Object Type property and other metadata about the resource. Object Manager is a shared resource, and all subsystems that deal with the resources have to pass through the Object Manager.

<span class="mw-page-title-main">Archival Resource Key</span> Form of URLs used as persistent identifiers

An Archival Resource Key (ARK) is a multi-purpose URL suited to being a persistent identifier for information objects of any type. It is widely used by libraries, data centers, archives, museums, publishers, and government agencies to provide reliable references to scholarly, scientific, and cultural objects. In 2019 it was registered as a Uniform Resource Identifier (URI).

An Extensible Resource Identifier (XRI) is a scheme and resolution protocol for abstract identifiers compatible with Uniform Resource Identifiers (URI) and Internationalized Resource Identifiers (IRI), developed by the XRI Technical Committee at OASIS. The goal of XRI was a standard syntax and discovery format for abstract, structured identifiers that are domain-, location-, application-, and transport-independent, so they can be shared across any number of domains, directories, and interaction protocols.

The Entertainment Identifier Registry, or EIDR, is a global unique identifier system for a broad array of audiovisual objects, including motion pictures, television, and radio programs. The identification system resolves an identifier to a metadata record that is associated with top-level titles, edits, DVDs, encodings, clips, and mashups. EIDR also provides identifiers for video service providers, such as broadcast and cable networks.

<span class="mw-page-title-main">Persistent identifier</span> Long-lasting digital name

A persistent identifier is a long-lasting reference to a document, file, web page, or other object.

<span class="mw-page-title-main">MIRIAM Registry</span>

The MIRIAM Registry, a by-product of the MIRIAM Guidelines, is a database of namespaces and associated information that is used in the creation of uniform resource identifiers. It contains the set of community-approved namespaces for databases and resources serving, primarily, the biological sciences domain. These shared namespaces, when combined with 'data collection' identifiers, can be used to create globally unique identifiers for knowledge held in data repositories. For more information on the use of URIs to annotate models, see the specification of SBML Level 2 Version 2.

Identifiers.org is a project providing stable and perennial identifiers for data records used in the Life Sciences. The identifiers are provided in the form of Uniform Resource Identifiers (URIs). Identifiers.org is also a resolving system, that relies on collections listed in the MIRIAM Registry to provide direct access to different instances of the identified records.

Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management. Originally designed by Google, the project is now maintained by a worldwide community of contributors, and the trademark is held by the Cloud Native Computing Foundation.

The Quake Markup Language (QuakeML) is a flexible, extensible and modular XML representation of seismological data which is intended to cover a broad range of fields of application in modern seismology.

<span class="mw-page-title-main">Well-known URI</span>

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.

References

  1. 1 2 "RFC 3650: Handle System Overview".
  2. "Kahn/Wilensky Architecture". CNRI. 1995-05-13. Retrieved 2013-03-13.
  3. "DONA Foundation". dona.net.
  4. "Digital Object Identifier System". doi.org.
  5. 1 2 "Redirect to Current Handle.Net web site content". handle.net. Retrieved 15 March 2018.
  6. "RFC 3651: Handle System Namespace and Service Definition".
  7. "RFC 3652: Handle System Protocol (ver 2.1) Specification".
  8. "handle.net". handle.net. Retrieved 2013-03-13.
  9. "About "info" URIs – Frequently Asked Questions". Info-uri.info. Retrieved 2013-03-13.
  10. "RFC 4452: The "info" URI Scheme for Information Assats with Identifiers in Public Namespaces".
  11. "DOI Handbook". International DOI Foundation . doi:10.1000/182. Archived from the original on 16 September 2022.
  12. "HDL.NET Services: Proxy Server System". Handle.net. Retrieved 2013-03-13.
  13. "HS Software Download". Handle.net. Retrieved 2013-03-13.
  14. "Software Client Libraries". Handle.net. Retrieved 2013-03-13.
  15. "HDL Plug-in for Adobe Acrobat and Acrobat Reader". Handle.net. Retrieved 2013-03-13.
  16. "Redirect to Current Handle.Net web site content". handle.net. Archived from the original on September 5, 2015.
  17. "DOI System Tools". Doi.org. 2012-07-12. Retrieved 2013-03-13.
  18. "adlnet.gov". adlnet.gov. Retrieved 2013-03-13.
  19. "SCORM". adlnet.gov. Archived from the original on 2008-06-14.
  20. "doi.org". doi.org. 2013-01-08. Retrieved 2013-03-13.
  21. "Identifier Systems in Network Architecture, Laurence Lannom, CNRI. Video of presentation (or presentation PDF only) from the Digital Motion Picture Metadata Symposium, Science & Technology Council, Academy of Motion Picture Arts & Sciences, 11 June 2009". Oscars.org. 2012-08-24. Archived from the original on 2013-03-30. Retrieved 2013-03-13.
  22. "workbook on digital private papers | administrative and preservation metadata | persistent identifiers". paradigm. 2008-01-02. Archived from the original on 2013-03-29. Retrieved 2013-03-13.
  23. "Handle System". Itu.int. 2010-04-16. Retrieved 2013-03-13.
  24. "LICENSE" (PDF). www.handle.net. Retrieved 2020-05-11.
  25. "dorepository.org". dorepository.org. 2013-01-08. Retrieved 2013-03-13.
  26. "Digital Object Repository Server: A Component of the Digital Object Architecture". Dlib.org. 2010-02-04. Retrieved 2013-03-13.
  27. Reilly S, Tupelo-Schneck R (January 2010). "Digital Object Repository Server: A Component of the Digital Object Architecture". D-Lib Magazine . DO Repository. 16 (1/2). doi: 10.1045/january2010-reilly . ISSN   1082-9873 . Retrieved 2013-03-13.
  28. "Cordra". cordra.org.