Handle System: Persistent Identifiers for Digital Object Architecture
In the rapidly evolving landscape of digital information, ensuring that a link remains functional over time is a significant challenge. The Handle System provides a robust solution to this problem by offering a proprietary registry that assigns persistent identifiers—commonly known as handles—to information resources. Unlike standard web links that may break when a file is moved, a handle acts as a permanent anchor, resolving into the necessary information to locate and access a resource regardless of changes to its underlying storage.
Developed by Bob Kahn at the Corporation for National Research Initiatives (CNRI) as part of the Digital Object Architecture (DOA), the system was conceived during the early deployment of the World Wide Web. Funded by DARPA between 1992 and 1996, the Handle System was designed to provide a distributed framework for digital object services, ensuring long-term stability for scholarly, professional, and government documents.
Key Facts
- Function: Assigns opaque, persistent identifiers to resources to prevent link rot.
- Core Components: Consists of a prefix (naming authority) and a suffix (local name).
- Administration: Managed by the DONA Foundation through a multi-primary administrator (MPA) model.
- Scale: Receives over 200 million resolution requests per month.
- Applications: Powers major systems like Digital Object Identifiers (DOI) and DSpace.
- Licensing: Available under a royalty-free public license similar to open source.
How the Handle System Works
A handle is opaque, meaning the identifier itself contains no information about the resource's location or type. Instead, the handle is bound to metadata—data that describes the resource. This metadata can include the resource's current location, available formats, and access permissions (such as whether the content is free or paid).
This architecture creates a fundamental distinction between a handle and a Uniform Resource Locator (URL). While a URL encodes specific details like the server hostname and file path, a handle only points to the metadata. If a resource moves to a new server, only the metadata needs to be updated; the handle remains exactly the same. This process of using a Resolver (a server that exchanges the handle for metadata) to find the resource is known as resolution.
Structure of a Handle
Handles are composed of two distinct parts: a prefix and a suffix.
- Prefix: Identifies the "naming authority." Prefixes are issued to authorities by the system's administrators upon payment of an annual fee. Prefixes can represent a hierarchy, such as
20.1000, where20is the CNRI prefix and1000is a subordinate authority. - Suffix: Provides the "local name" of the resource within that specific namespace. Suffixes can use any characters from the Unicode UCS-2 character set.
For example, the handle 20.1000/100 uses the prefix 20.1000 to identify the authority and 100 as the specific resource name.
System Implementation and Scale
The Handle System operates as a distributed network. It consists of Local Handle Services, which store specific handles, and a Global Handle Registry (GHR), which tracks where those local services are located. When a user requests a handle, the GHR directs them to the correct Local Handle Service, which then provides the information needed to access the resource.
| Metric | Details |
|---|---|
| Monthly Resolution Requests | Over 200 million |
| Active Handle Services | Thousands globally |
| University/Library Presence | Over 1,000 services |
| Global Reach | 71 countries across 6 continents |
| Total Prefixes (as of 2014) | Over 12,000 |
Design Principles for Persistence
To ensure that identifiers remain reliable over decades, the system adheres to strict design requirements:
- Non-dependency: The identifier string is not based on changeable attributes like ownership or location.
- Uniqueness: Every identifier is unique within the system to prevent collisions.
- Reliability: The resolution mechanism uses redundancy to avoid single points of failure.
- Scalability: The system can handle increased loads by adding more computing resources.
- Flexibility: The architecture can adapt to new computing environments and applications.
Common Applications
Because of its stability, the Handle System is widely used across various sectors. It is the underlying infrastructure for Digital Object Identifiers (DOI), which are essential for identifying scholarly journal articles, books, and datasets. Other applications include:
- Technical reports and government documents.
- Theses and dissertations.
- Distributed learning content.
- Digital watermarking and GRID applications.
- Institutional repositories like DSpace.
Frequently Asked Questions
How does a handle differ from a URL?
A URL contains specific information about where a file is located (like a server name), so if the file moves, the URL breaks. A handle is an opaque identifier that points to metadata; if the file moves, you simply update the metadata, and the handle remains valid.
What is "link rot" and how does this system prevent it?
Link rot occurs when web links become broken because the underlying resource has moved or been deleted. The Handle System prevents this by ensuring the identifier never changes, even when the resource's location or attributes do.
Can handles be used as web addresses?
Yes. While handles are native identifiers, they can be expressed as Uniform Resource Identifiers (URIs) or accessed via a generic HTTP proxy server, such as https://hdl.handle.net/20.1000/100.
Who manages the Handle System?
The system is currently administered by the DONA Foundation, which manages the Global Handle Registry and accredits multi-primary administrators (MPAs), including the CNRI and the International DOI Foundation.
Is the Handle System software free to use?
CNRI provides the specifications and source code for reference implementations under a royalty-free public license, allowing for both commercial and non-commercial use at a low cost.