Resolver Landing Page¶
Interface — instantiates Persistent Identifier Stewardship
The human-readable page a resolver returns — stating what the identifier denotes and showing the disambiguating detail a person needs to confirm they reached the right entity.
Resolver Landing Page is the interpretive surface a persistent identifier resolves to when the point is to let a human understand what they have reached, not just be shot straight at a file. Its defining move is to make resolution legible: instead of a silent redirect into a raw object, the identifier lands on a page that says, in plain terms, what this token denotes and at what granularity — a work, a specific version, a specimen, a continuing dataset — and shows enough metadata that a person can confirm this is the right entity before they act on it. It is neither the engine that performed the lookup nor the policy that chose the version; it is the page a human reads to answer "is this the thing I was looking for, and what is its current status?"
Example¶
A national art museum assigns a persistent URL to a particular painting in its collection. Resolving that URL does not dump the reader onto a bare TIFF; it lands on a page that states the identifier denotes the artwork as a continuing object — not any single photograph of it — and then lays out the disambiguating detail: title, artist, accession number, date, current gallery or loan status, and links to the available high-resolution images and to the conservation record.
A conservator chasing a decades-old catalog reference arrives here and, even though the painting was since reattributed to a different workshop and moved twice between storerooms, confirms from the accession number and provenance that it is the same object the old note meant. The landing page did the one thing a redirect cannot: it let a human verify the referent and read its current standing, then choose which representation to open.
How it works¶
The resolver routes an incoming token to this page, which then composes a human-first view:
- State the scope. Say explicitly what the identifier denotes and at what granularity, so a reader is not left guessing whether the token means the work, an edition, or a copy.
- Show disambiguating metadata. Present the fields a person needs to confirm the intended entity — identifiers, dates, creators, provenance, current status.
- Offer onward paths. Link to the actual representations, versions, rights/access routes, and related or successor records.
It reads the entity's metadata and presents it; it does not itself perform the lookup, enforce access, or decide which version is current.
Tuning parameters¶
- Metadata richness — thin (a title and a link) versus deep (full provenance, versions, rights). Richer pages disambiguate better but cost more to maintain and can bury the entity.
- Directness — land on the page first, or content-negotiate straight to the object for machine clients. Interpretability versus friction for callers who already know what they want.
- Scope prominence — how loudly the page states what the token denotes. Loud scope prevents misinterpretation; understated scope reads cleaner.
- Machine-readability — embed structured metadata (JSON-LD, schema.org) alongside the human view, or keep it human-only. Structured markup aids reuse but adds upkeep.
- Historical exposure — show superseded, withdrawn, or successor states in context, or display only the current entity.
When it helps, and when it misleads¶
Its strength is that it lets a person confirm the referent and read provenance, rights, and version choices before touching the entity — the difference between a citation that can be trusted and one that merely resolves. It is what operationalizes the "Findable" and "Accessible" promises of the FAIR principles:[1] a durable token is only findable in practice if resolving it yields interpretable context.
Its failure mode is the landing page to nowhere — the page survives a migration but its onward links rot, so the reader gets metadata about an entity they can no longer reach, or a status with no explanation. A subtler failure is metadata too thin to disambiguate, leaving two similar entities indistinguishable. The classic misuse is letting the page bloat with marketing or SEO furniture until the identity information a citation depends on is crowded off the screen. The discipline is to keep the page interpretive and lean, always carrying a working path onward and enough metadata to tell this entity from its neighbors — and to treat a broken onward link as a defect the monitor must catch.
How it implements the components¶
Resolver Landing Page realizes the human-interpretation slice of the archetype — the parts a reader consumes:
disambiguating_metadata_record— its visible content is this record: the fields a human reads to confirm they reached the intended entity and not a look-alike.identity_scope_definition— it states in plain language what the token denotes and at what granularity, turning the abstract scope commitment into something a reader can see.
It does NOT perform the lookup or enforce the access_and_rights_boundary (that's Persistent Identifier Resolver Service), nor decide which version to display (version_selection_policy — Identifier Version Resolution Rule); the landing page only presents what the resolver hands it.
Related¶
- Instantiates: Persistent Identifier Stewardship — the landing page is the interpretive endpoint of resolution.
- Consumes: Persistent Identifier Resolver Service — the resolver routes the token here and supplies the resolved context the page renders.
- Sibling mechanisms: Persistent Identifier Resolver Service · 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: Interface, Display & Cue
Rationale: Resolver Landing Page operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it the human-readable page a resolver returns — stating what the identifier denotes and showing the disambiguating detail a person needs to confirm they reached the right entity.
Independent corroboration: The frozen evidence defines Resolver Landing Page as 'The human-readable page a resolver returns — stating what the identifier denotes and showing the disambiguating detail a person needs to confirm they reached the right entity', so its operative form is Interface, Display & Cue.
Nearest alternative: Representation, Specification & Plan — Resolver Landing Page includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Human-readable identifier descriptions and disambiguating authority records arise from information organization.
Related originating lineages:
- Computer Science & Software Engineering — Web resolver infrastructure supplies identifier lookup and redirection.
- Human-Computer Interaction — Interface design materially shapes confirmation-oriented landing pages.
Review resolution: Both blind reviewers agree that library_information_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement adopts reviewer_a's evidence: Human-readable identifier descriptions and disambiguating authority records arise from information organization. The selected record uses alternates=computer_science, human_computer_interaction, origin_mode=cross_disciplinary_synthesis, and domain_reach=multi_domain; the other review proposed alternates=computer_science, origin_mode=single_lineage, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
This mechanism is the heart of the landing-page identifier pattern, where resolution is deliberately interpretive rather than a silent redirect. The choice to land-then-link, versus resolving straight to the bytes, is the single design decision that separates identifiers meant for citation and stewardship from those meant only for fast machine access.
References¶
[1] The FAIR principles — Findable, Accessible, Interoperable, Reusable — a widely adopted framework (Wilkinson et al., 2016) for research-data stewardship. Its first principle explicitly requires a persistent identifier plus rich, resolvable metadata, which is precisely what a resolver landing page supplies. withdrawn registry ↩