Persistent Identifier Resolver Service¶
Service — instantiates Persistent Identifier Stewardship
Accepts a persistent token and returns its current usable target — looking up the live mapping and applying access rules — so callers never depend on where the entity currently lives.
Persistent Identifier Resolver Service is the always-on machine endpoint that turns a stable token into wherever the entity actually lives right now. It is the runtime face of the whole archetype: the one place where indirection is executed rather than merely declared. A caller hands it a token; it looks up the live mapping, applies whatever access and rights rules attach to that entity, and returns a current, usable target — a redirect, a structured resolution payload, or an explanatory status. What makes this the resolver service and not a sibling is that it neither renders a human page, nor decides which version to serve, nor holds the authoritative binding forever: it is the fast, stateless-feeling translation engine that fields every incoming resolution and answers in milliseconds.
Example¶
The California Digital Library runs N2T ("Name-to-Thing"), a resolver for ARK identifiers. A library mints an ARK such as ark:/12345/abcd for a digitized medieval manuscript and hands that string to catalogs and citations. When a reader's browser hits n2t.net/ark:/12345/abcd, the resolver service does its one job: it looks up the ARK's current mapping and sends the reader onward — today to a viewer on server A, next year, after a storage migration, to server B, with the ARK and the resolver URL never changing.
The service also enforces the entity's access boundary as it resolves. For an openly published manuscript it returns a plain redirect; for a specimen record under an embargo it returns a gated response — a rights notice or an authentication challenge — rather than leaking the protected target. The reader experiences a single durable address; behind it, the resolver has quietly absorbed a server move and a rights check that a hard-coded URL never could.
How it works¶
The service is a tight request loop, not a workflow:
- Accept and normalize the token. Parse the identifier, canonicalize case and prefix, and reject malformed input.
- Look up the live mapping. Read the current token-to-target mapping record — the datum that says where this entity resolves now.
- Apply the access and rights boundary. Gate, open, or challenge the request according to the entity's current rights state before any target is disclosed.
- Return resolution. Emit a redirect, a structured payload, or a status code, and cache it for a bounded time to absorb load.
Everything upstream — how the mapping got its current value, which version it points at, what happens when the target is gone — is decided by other mechanisms whose outputs the resolver merely reads and executes.
Tuning parameters¶
- Resolution mode — HTTP redirect, structured payload (content-negotiated metadata), or proxying the content. Redirects are cheap and transparent; proxying hides the target but makes the resolver a bottleneck.
- Cache TTL — how long a resolved target is reused before re-lookup. Longer caching cuts load but serves stale targets after a move.
- Enforcement point — apply the rights boundary at the resolver, or delegate it to the target. Enforcing early prevents leakage; delegating keeps the resolver simple.
- Topology — a single global resolver versus federated mirrors. One node is simplest and most consistent; mirrors add availability at the cost of reconciliation.
- Unknown-token behavior — return a hard error, a last-known target with a warning, or a referral to a landing page.
When it helps, and when it misleads¶
Its strength is that it collapses all mutable "where and how" questions into one address the rest of the world can hard-code safely. Callers store the token; the entity is free to move, re-host, or change representation, and nothing downstream breaks as long as the mapping is kept current.
Its characteristic failure is that it becomes a single point of failure:[n1] when the resolver is down, hijacked, or serving a stale cache, every reference that depends on it fails at once, and the very indirection that bought resilience now concentrates fragility. The classic misuse is treating a live resolver as if it were the authoritative store — hammering it as a general database, or letting a downstream cache quietly become the source of truth. The discipline that guards against this is to keep the resolver a thin, replicated read path with health checks and failover, and to let a dedicated monitor — not the resolver itself — watch for the resolution rot that a fast, uncomplaining redirect will otherwise hide.
How it implements the components¶
Persistent Identifier Resolver Service realizes the runtime-resolution slice of the archetype — the parts that execute at request time:
resolver_mapping_record— it reads and serves this record on every request; the mapping is the live datum it dereferences a token into a current target.access_and_rights_boundary— it enforces the entity's rights state at resolution time, opening, gating, or challenging the request before any target is disclosed.
It does NOT render the human-readable page or expose the disambiguating_metadata_record (that's Resolver Landing Page), decide which version a bare token serves (version_selection_policy — Identifier Version Resolution Rule), or watch for decay (resolution_integrity_monitor — Resolution Link Checker); it is the machine endpoint, not the page, the policy, or the monitor.
Related¶
- Instantiates: Persistent Identifier Stewardship — the resolver service is the runtime engine every resolution passes through.
- Consumes: Identifier Version Resolution Rule to choose a version and Redirect and Tombstone Policy to handle moved or withdrawn targets — it applies both during a lookup.
- Sibling mechanisms: Resolver Landing Page · Identifier Version Resolution Rule · Redirect and Tombstone Policy · Custodial Transfer Protocol · Resolution Link Checker · Identifier Registry · Identifier Minting Workflow
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Persistent Identifier Resolver Service operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it accepts a persistent token and returns its current usable target — looking up the live mapping and applying access rules — so callers never depend on where the entity currently lives.
Independent corroboration: The frozen evidence defines Persistent Identifier Resolver Service as 'Accepts a persistent token and returns its current usable target — looking up the live mapping and applying access rules — so callers never depend on where the entity currently lives', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Resolver services descend from persistent scholarly and archival identifier infrastructures.
Related originating lineages:
- Computer Science & Software Engineering — Persistent Identifier Resolver Service is rooted in computer science and software engineering: Service engineering makes maintained identifier mappings highly available, replicated, and access-aware. Web-service lookup, access control, and redirect implementation supplied the operational service form.
- Engineering & Design — Engineering and design materially shaped Persistent Identifier Resolver Service through reliability, physical systems, safety, and mistake-proof design.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of library, archival, and information science. DOI Handbook: Identifier and Resolution Services directly documents the defining practice or theory described in the selected origin rationale. Other listed domains are retained only where the blind reviews identify material co-development or translation; broader adoption remains separate as domain_reach=multi_domain.
Attribution caveat: The boundary with computer science and software engineering is real because that field materially developed or translated the practice, but the cited provenance places the defining form in library, archival, and information science.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
Three layers are easy to conflate and must stay separate: the resolver service executes resolution at speed; the Resolver Landing Page interprets it for a human; and the authoritative binding store (an Identifier Registry, in the neighboring binding archetype) holds the ground truth the resolver reads from. A system stays honest by letting the resolver be a fast, disposable read path — never the book of record.
[n1] Single point of failure — a component whose loss halts the whole system because nothing else can perform its function. Reliability engineering's standard response is redundancy (mirrors, failover), which is exactly why a persistent-identifier program must replicate its resolver rather than trust one node. ↩