Alias Redirect Table¶
Redirect table — instantiates Durable Identifier Binding
A maintained map from superseded, variant, or legacy identifiers to the current canonical handle, so old references keep resolving.
Alias Redirect Table is the mechanism that preserves access through change. When a referent's canonical identifier changes — after a merge, a rename, or a migration — or when the same referent is reachable under several variant forms, the table maps every old, alternate, and legacy handle to the current canonical one. Its defining move is that it never lets a live reference dead-end: it forwards, and it records the predecessor-to-successor link so the change is traceable rather than silent. It is a mapping and forwarding layer — not the engine that resolves handles, and not the register that decides when one is retired.
Example¶
A documentation site restructures and moves /docs/v1/getting-started to /guide/start. Every existing bookmark, search result, and inbound link still points at the old path. The alias redirect table maps the old path to the new one and, on request, forwards visitors with an HTTP 301 ("moved permanently"); people and crawlers land on the current page transparently. The table also records that /guide/start is the successor of /docs/v1/getting-started, so the lineage is auditable. Over years the table accumulates whole chains of moves — and it collapses them, so a request for the oldest URL resolves straight to the newest target in one hop rather than bouncing through every intermediate.
How it works¶
The table is many-to-one canonicalization plus forwarding. Each entry maps an alias, variant, or legacy handle to the current canonical handle, tagged with the relation it represents — alias-of, variant-of, or superseded-by. Given a reference to any non-canonical handle, the table returns the canonical target and, optionally, the redirect semantics (permanent versus temporary). It collapses multi-hop chains (A → B → C resolves directly to C) to keep forwarding cheap. What it supplies is the old-to-new correspondence; the actual act of resolving and any access control are applied by the resolver that consults it.
Tuning parameters¶
- Redirect permanence — permanent (301, "the canonical handle has moved") versus temporary (302). Permanent lets caches and search engines consolidate onto the new handle; temporary keeps the old one authoritative for now.
- Chain collapsing — resolve multi-hop chains straight to the final target versus preserve each hop. Collapsing is fast; preserving keeps the full lineage visible.
- Variant coverage — how many alternate forms are mapped in (casing, punctuation, retired schemes, common misspellings). Broad coverage maximizes recall but risks mapping a genuinely distinct thing onto the wrong canonical handle.
- Directionality — one-way (old → new) versus also exposing new → old history. Reverse links aid audit but add maintenance.
- Expiry — whether stale aliases ever retire. Never expiring maximizes the durability of old references; expiry controls table growth.
When it helps, and when it misleads¶
Its strength is that it is the antidote to link rot[1] — the steady decay of references as things are moved, renamed, or reorganized — and it lets a system restructure freely without stranding every citation ever made to it. It also makes merges and splits navigable: after a merge, all of the absorbed entity's old identifiers forward to the survivor.
Its failure is subtler and more dangerous than a broken link: mapping the wrong things together. An over-eager alias that collapses two genuinely distinct referents onto one canonical handle silently merges them, and a silent merge is far harder to notice than a 404. Loops and redirects to already-retired targets are the other hazards. The classic misuse is using redirects to quietly erase history — pointing an old, meaningful identifier at unrelated current content. The discipline is that an alias must be a true same-referent correspondence, checked against the identity-persistence criteria, and successor links should be auditable rather than silently overwritten.
How it implements the components¶
Alias Redirect Table realizes the access-through-change side of the archetype — the correspondences that keep old references alive, not the resolution engine or the lifecycle record:
alias_and_variant_access_map— its core content: the table of alias, variant, and legacy handles mapped to the current canonical handle.successor_predecessor_relation— each redirect for a superseded handle records the predecessor-to-successor lineage, keeping replacements traceable.
It does NOT perform the actual resolution or enforce who may access the target (that's Persistent Identifier Resolver), decide when an identifier is retired or superseded (that's Identifier Lifecycle Register), or judge whether two handles truly share a referent (that's Collision Detection Review).
Related¶
- Instantiates: Durable Identifier Binding — the table keeps historical and variant references resolving after the canonical handle changes.
- Consumes: Identifier Lifecycle Register — the supersession and retirement events it records are what create new redirect entries.
- Sibling mechanisms: Persistent Identifier Resolver · Identifier Lifecycle Register · Identifier Registry · Identifier Minting Workflow · Accession Numbering Protocol · Check-Digit or Format Validation · Collision Detection Review · Identifier Reservation Queue · Namespace Prefix Registry · UUID or Random Token Generator
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: A maintained map from superseded, variant, or legacy identifiers to the current canonical handle, so old references keep resolving, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Alias Redirect Table as 'A maintained map from superseded, variant, or legacy identifiers to the current canonical handle, so old references keep resolving', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Maintaining redirects from legacy identifiers to canonical handles is established software, web, and database compatibility practice.
Related originating lineages:
- Library & Information Science — Authority control and cross-reference catalogs developed parallel practices for variant names.
Review resolution: Both reviewers agree exactly on the computer-science primary, library-information alternate, convergent mode, reach, confidence, and synthesis status. The residual commentary does not represent provenance uncertainty, so the clean final record omits ambiguity.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The redirect table is the data; the Persistent Identifier Resolver is the engine that applies it. Keeping the mapping separate from the resolution logic lets the same old-to-new correspondences drive web redirects, database key remaps, and citation fixes without re-implementing forwarding in each place — and lets the resolver stay ignorant of why a handle moved, only where it now points.
References¶
[1] Berners-Lee, T. "Cool URIs Don’t Change". World Wide Web Consortium (1998). Explains why stable URIs prevent dangling links when sites, files, names, and organizational structures change. registry ↩