Translation Register¶
Governance ledger — instantiates Schema Conflict Resolution
A living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays maintained instead of going stale.
A resolution that isn't owned quietly rots. Translation Register is the governance artifact that keeps it alive: a maintained ledger of every translation rule currently in force between schemas, and for each one, who owns it, when it was last reviewed, and which ambiguities it still hasn't settled. Its defining property is that it is a living record, oriented to maintenance over time rather than to a one-time build — its central columns are stewardship and open questions, not the mechanics of a single conversion. Where other mechanisms produce a mapping, the register answers the question that decides whether the mapping survives contact with change: who keeps this true, and what do we still not know?
Example¶
A state health-and-human-services department administers benefits across several programs — Medicaid, food assistance, and cash aid — each with its own eligibility category system, plus federal categories they must report against. Translation rules already exist for moving a client's status between these schemas, but they were written by different teams at different times. The register pulls them into one ledger. Each rule gets an entry: the rule itself, the program analyst who owns it, the schema versions it applies to, its last-reviewed date, and an open-ambiguities field. That last field is doing real work — the entry for translating "household composition" between the food-assistance and cash-aid schemas notes an unresolved case (a minor splitting time between two households) that neither program's rule cleanly handles, so caseworkers know it is a known gap, not a decided answer. When federal reporting categories change next fiscal year, the register is what tells the department exactly which rules need rework and who is on the hook to do it — instead of the change silently invalidating a mapping nobody remembers owning.
How it works¶
- Enter every in-force rule. Each translation rule currently used between the schemas gets a durable entry, so the full set is visible in one place rather than scattered across specs and memories.
- Assign an owner to each. Every rule names an accountable person or role responsible for keeping it valid — an unowned rule is treated as a defect, not a rule.
- Log what's still open. Each entry carries the ambiguities the rule hasn't resolved, so known gaps stay visible instead of being mistaken for settled answers.
- Trigger review on change. Version stamps and a review cadence turn a schema change into a work item routed to the owner, rather than silent staleness.
Tuning parameters¶
- Review cadence — how often entries are revisited (event-triggered vs. periodic). Frequent review catches drift early but costs owner attention.
- Ownership granularity — one steward for the whole register versus a named owner per rule. Per-rule ownership scales accountability but risks fragmentation and orphaned entries.
- Ambiguity tolerance — how many open questions a rule may carry while still in force. Higher tolerance keeps the system running but accumulates latent risk.
- Change-trigger tightness — how aggressively schema changes are flagged as review work. Tighter triggers prevent staleness but generate more churn for owners.
When it helps, and when it misleads¶
Its strength is durability: it directly attacks the way resolutions die — unmaintained rules, departed authors, changes that silently invalidate a mapping — by making stewardship and open questions first-class, visible facts. This is the data-stewardship discipline applied to translation: assigning accountable humans to the meaning of shared data over its whole life.[n1]
Its failure mode is register theater of its own: a ledger that lists owners who don't actually review, and open-ambiguity fields that fill up but never get worked, so the artifact documents decay instead of preventing it. The classic misuse is standing up the register once, populating it in a burst of diligence, and never running the review cadence — leaving a snapshot that ages into fiction. The guarding discipline is to tie the register to a live trigger (schema-change events and a real cadence) and to hold owners accountable for closing or explicitly re-affirming their open ambiguities, so the ledger reflects the present rather than the day it was built.
How it implements the components¶
translation_rule— the register holds the authoritative, in-force set of translation rules between the schemas, each as a maintained entry.semantic_owner— every rule names an accountable steward responsible for keeping it valid as schemas change.residual_ambiguity_log— each entry carries the still-open questions the rule hasn't settled, kept visible rather than forgotten.
It governs rules over time but does not decide the resolution mode (integration_decision) — that is Ontology Mapping Workshop — and it stops at the rule level rather than specifying an executable field transform with its exception routing (exception_handling_path) — that is Data Mapping Specification.
Related¶
- Instantiates: Schema Conflict Resolution — the maintenance layer that keeps a resolution's translation rules owned, versioned, and honest about their gaps.
- Consumes: Data Mapping Specification — supplies the concrete translation rules the register places under stewardship.
- Sibling mechanisms: Boundary-Spanner Review Session · Case-Based Mapping Test · Data Mapping Specification · Glossary Alignment Table · Ontology Mapping Workshop · Schema Crosswalk Table · Semantic Interoperability Review · Taxonomy Reconciliation Review
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Translation Register operates as a persistent ledger, log, register, or case record that preserves history and traceability because it a living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays maintained instead of going stale.
Independent corroboration: The frozen evidence defines Translation Register as 'A living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays maintained instead of going stale', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: GALA, TermBase eXchange (TBX) 3 defines maintained concept-oriented terminology records with identifiers, language mappings, administrative metadata, and versionable status. This directly supports library information science as the best-evidenced historical home of the operation—A living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays maintained instead of going stale.—while the alternates record adjacent lineages rather than mere domains of later use.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: a living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays….
- Linguistics & Semiotics — Linguistics, pragmatics, and semiotic analysis supplies a parallel or contributing lineage for the mechanism's defining operation: a living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays….
- Mathematics — Mathematics supplies a historically relevant adjacent lineage or formative practice for the operation—A living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays maintained instead of going stale.—but the researched evidence more directly locates the defining lineage in library information science.
Review resolution: The blind reviewers disagree on primary lineage (mathematics versus library_information_science). The defining operation is: A living ledger of the translation rules in force between schemas — each with a named owner, a version, and the open ambiguities it hasn't yet settled — so a resolution stays maintained instead of going stale. The researched GALA, TermBase eXchange (TBX) 3 defines maintained concept-oriented terminology records with identifiers, language mappings, administrative metadata, and versionable status. That is mechanism-specific evidence for library information science as the historical origin. Mathematics remains represented among the uncapped alternates where it contributes a genuine formative practice, but broad deployment or governance of the operation is not by itself evidence that the mechanism originated there. origin_mode=single_lineage records lineage; domain_reach=universal separately records later applicability.
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¶
[n1] Data stewardship is the practice of assigning accountable people to define, maintain, and vouch for the meaning and quality of shared data assets over their lifecycle — the organizational counterpart to the register's insistence that every translation rule have a named owner. ↩