Alias Resolution Table¶

Reference artifact — instantiates Equivalence Class Consolidation

A stored lookup that maps every alternate name, spelling, code, or identifier for a thing to its one canonical representative, so any variant resolves to the same entry.

An Alias Resolution Table is the persisted map at the centre of a consolidation: a table whose rows say "this variant → that canonical." It is deliberately not the judgment that two things are the same, and not the process that finds them — it is the artifact that records the decision so anyone (or any query) can look up a raw variant and get back the one canonical form the class agreed on. Its whole reason to exist is durable, cheap resolution at the point of use: paste in a misspelling, a legacy code, or a local nickname, and read out the single representative everything else keys on. Everything upstream — deciding the criterion, inferring the matches, choosing which form is canonical — is somebody else's job; this table just holds the answer.

Example¶

A university library catalog holds works credited to "Twain, Mark," "Clemens, Samuel L.," "Mark Twain," and "S. L. Clemens." They are one author. The library keeps an authority file^[1] — an alias resolution table for names — that designates a single canonical heading ("Twain, Mark, 1835–1910") and lists the other forms as see-references pointing to it. When a patron searches any of the variants, or when a new acquisition arrives credited under an old pen name, the lookup lands on the same authority record. The catalog can then show every work by that person together, even though the source metadata spelled the name four different ways. The table changed nothing about the books; it changed the fact that four surface names now resolve to one entry.

How it works¶

What distinguishes this mechanism is that it is a stored structure consulted at read time, not an activity:

Each row binds a variant key (a spelling, encoding, legacy identifier, local label) to the canonical representative for its class, plus which form is flagged preferred.
Lookups are direct: hand it a variant, get the canonical back — the resolution is O(1), not a fresh comparison.
It is downstream of the equivalence decision. The table encodes conclusions reached elsewhere; it never re-derives them. Adding a row is asserting "this belongs to that class," which is why rows carry provenance.

Tuning parameters¶

Key normalization — whether variant keys are stored raw or lightly folded (case, whitespace, diacritics) before matching. More folding catches more variants automatically but risks colliding genuinely different keys.
Directionality — a strict one-canonical-per-class table versus a symmetric synonym ring with no single preferred form. Directionality is what makes substitution unambiguous; symmetry preserves neutrality between forms.
Read-time match mode — exact-key lookup versus fuzzy lookup that tolerates near-misses. Fuzzy read absorbs unseen variants but reintroduces false hits the table was meant to eliminate.
Scope binding — whether the table is authoritative everywhere or only within one registry/tenant. Narrow scope prevents an equivalence true in one context from leaking into another.
Provenance depth — how much per-row justification (who, when, on what evidence) is stored alongside the mapping.

When it helps, and when it misleads¶

Its strength is a single, cheap, durable point of resolution: old names stay discoverable, downstream systems stop diverging, and nobody has to re-adjudicate a match that was already settled. It is the artifact that makes a consolidation usable rather than merely decided.

Its classic failure is the homograph collision — two genuinely distinct entities that happen to share a surface form (two authors named "J. Smith," two products with the same local code). A naïve alias table silently routes both to one canonical entry and fuses records that should never have touched. Its second failure is staleness: the world moves, an alias that was safe becomes ambiguous, and the table keeps confidently returning yesterday's answer. The misuse to watch is treating the table as proof of equivalence when it is only a record of one — freezing a bad merge behind a fast lookup. The discipline that guards against both is to keep the table strictly downstream of an explicit criterion and a live review path, and to store provenance on every row so a suspect mapping can be traced and reversed.

How it implements the components¶

alias_mapping — the table is the alias mapping made concrete: the rows that connect noncanonical names, codes, and forms to their class.
canonical_representative — every row terminates at the designated preferred form, and the table is where that choice is looked up.

It does not decide which records refer to the same entity — that inference belongs to Identity Resolution Model — nor does it define the sameness criterion or run the merge (that is Deduplication Workflow), nor set the policy for which form becomes canonical (that is Master Record Consolidation). It only stores the resulting map.

Instantiates: Equivalence Class Consolidation — the Alias Resolution Table is the persisted artifact that makes a consolidation resolvable at the point of use.
Consumes: Identity Resolution Model supplies the matches whose conclusions the table stores.
Sibling mechanisms: Deduplication Workflow · Master Record Consolidation · Canonicalization Pipeline · Crosswalk Table · Equivalence Test Suite · Identity Resolution Model · Policy Equivalence Rule · Synonym Merge Review · Taxonomy Merge Workshop · Unit Normalization Table

References¶

[1] Authority control is the library-science practice of maintaining a single authorized form of a name, subject, or title with cross-references from its variants — exactly an alias resolution table for bibliographic entities. Shared authority files such as VIAF federate these across institutions. ↩