PID resolution

PID resolution is the middle step of a persistent identifier’s lifecycle — mint, resolve, update, tombstone — and the one a reader interacts with directly: it is the act of dereferencing an identifier and getting back either the resource itself or metadata about it. A scheme’s resolvability, not just its uniqueness, is what makes it “persistent” in practice: an identifier that never changes but cannot be resolved has lost its usefulness. See PID minting for the create step this follows.

How resolution actually works

Most researcher-facing PID schemes resolve over HTTP. A client sends a request to a resolver — https://doi.org/10.xxxx/yyyy for a DOI, https://hdl.handle.net/prefix/suffix for a bare handle, https://orcid.org/0000-… for an ORCID iD — and the resolver responds with a 302 redirect to the resource’s current landing page, or, under content negotiation (an Accept header requesting a structured format), with machine-readable metadata instead of a redirect. The Handle System underlying DOIs additionally supports a native HDL protocol for high-throughput or offline resolution, alongside the HTTP proxy most users actually see. ARKs layer a further convention on top of ordinary HTTP resolution — see ARK inflection rules — where appending ‘?’ or ‘??’ to the same base URL returns metadata or a persistence-policy statement instead of the object.

Scheme-specific and cross-scheme resolvers

Most resolvers serve a single scheme — doi.org is the central proxy for DOIs (running over the Handle System underneath), hdl.handle.net resolves bare handles, and orcid.org resolves ORCID iDs. Cross-scheme resolvers also exist: n2t.net (Name-to-Thing), operated by the California Digital Library, resolves ARKs, DOIs, Handles and a long tail of other prefixes through a single endpoint, which is what makes it useful to systems holding mixed identifier types that would otherwise have to route each one to its own proxy. Whichever resolver is used, content negotiation is the common convention: the same identifier returns an HTML landing page or machine-readable metadata depending on the request’s Accept header.

Resolver failure is not identifier failure

A dead link at the resolver (a 404, an expired redirect target) is a failure of the resolution infrastructure or of the metadata record behind it, not evidence that the identifier scheme itself is broken — the distinction matters for diagnosing link rot. Schemes differ in how resilient their resolution layer is: the Handle System’s distributed, replicated resolver network is deliberately designed to avoid a single point of failure, where a scheme relying on one organisation’s redirect table is only as durable as that organisation’s continuity. Who stands behind a given resolver — and what happens to it if that organisation ceases operating — is the subject of PID provider.

References

• Sun S., Lannom L., Boesch B., RFC 3650-3652 (Handle System), IETF, 2003.
• Kunze J., Calvert S., DeBacker J., Hanlon R., Jordan M., Pentecost C., ‘Persistence Statements: Describing Digital Stickiness’, Data Science Journal 16(39), 2017.