Schema Mapping Table¶
A concrete mapping artifact — instantiates Structure-Preserving Embedding Design
A field-by-field table that lays every source element beside its host target and transform, and turns each element with no faithful home into a visible row.
Where the map specification declares the rule abstractly, the Schema Mapping Table instantiates it exhaustively — one row per source element — and its distinctive power is that the gaps become rows too. A field that has nowhere to go in the host, or a cast that quietly loses precision, cannot hide: the empty target cell is sitting right there on the page. The table is at once a complete census of the source (an inventory) and a running ledger of everything that will not survive intact (a loss register). It consumes the Structure-Preserving Map Specification — it is the rule made line-by-line concrete.
Example¶
A company is migrating customer records from an old CRM to a new one. Every source field gets a row: source field, its type, the host field, the transform, and a note. full_name splits into first_name + last_name; region_code maps to territory through a lookup; created_at, stored in local time, casts to a UTC created_at — flagged lossy, because the original offset history is dropped. And preferred_fax maps to nothing at all: no host field exists, so it becomes a row in the loss register with the reason attached.
The outcome is a decision made before data moves rather than after. Seeing the two doomed fields as explicit rows, the team chooses to build a small host extension to rescue one of them and to consciously abandon the other — a deliberate call on the record, instead of a silent disappearance discovered months later when someone goes looking for a fax number that was never carried across.
How it works¶
- One row per source element, so the enumeration is exhaustive by construction and nothing is mapped implicitly.
- Each row records the correspondence and its transform — a rename, a split, a unit cast, a lookup — not merely that two fields are "the same."
- Unmapped and lossy elements are logged, not dropped. They become rows in the loss register with a stated reason, which is what makes the loss visible.
- The source column doubles as an inventory — a complete list of what the source actually contains, often the first time anyone has seen it whole.
Tuning parameters¶
- Coverage bar — must every source field appear, or only the "important" ones? Full coverage catches silent loss; partial coverage is faster but reopens the blind spot.
- Transform expressiveness — plain renames versus arbitrary per-row functions. Richer transforms map more but turn the table itself into a program that has to be tested.
- Loss tolerance — which lossy casts are acceptable and which block the migration. Tightening it turns more rows red and forces host-side changes.
- Confidence marking — whether each row carries a certain/uncertain flag. Marking surfaces guesses for review at the cost of extra columns.
When it helps, and when it misleads¶
Its strength is that it makes an integration auditable and forces the loss conversation up front. A metadata crosswalk — the mapping a library keeps between, say, Dublin Core and MARC — is exactly this artifact under its data-management name.[n1]
Its classic misuse is filling the table to look complete: leaving the loss register empty so the migration reads "clean," when in truth the unmapped fields were quietly discarded. It also flatters syntactic matches — two fields sharing a name and a type can mean entirely different things, and the table records the correspondence without checking that the meaning survives. The discipline is to require every source field to appear (an empty target is a finding, not an omission) and to let a semantic check, not name equality, confirm the hard matches.
How it implements the components¶
This mechanism realizes the enumerate-and-account side of the archetype — the concrete census and the honest ledger of loss:
source_structure_inventory— the source column is a complete census of the source's elements and their types.distortion_and_loss_register— every unmapped or lossy row is recorded with its reason, so loss is on the page rather than in production.
It does not state the abstract rule or the preservation contract it enumerates — those come from the Structure-Preserving Map Specification; whether the host will actually admit each value (types, constraints, interfaces) is the Adapter or Wrapper Layer's admissibility check; and whether meanings rather than names correspond is the Ontology Alignment Map.
Related¶
- Instantiates: Structure-Preserving Embedding Design — the table is the exhaustive, auditable instance of the embedding.
- Consumes: Structure-Preserving Map Specification supplies the injection rule and contract the table lays out row by row.
- Sibling mechanisms: Structure-Preserving Map Specification · Ontology Alignment Map · Vector Embedding Model · Round-Trip Validation Test · Serialization with Reconstruction Schema · Adapter or Wrapper Layer · Invariant Preservation Test Suite · Coordinate Chart Mapping · Graph Embedding · Embedding Collision Probe · Nearest-Neighbor Audit
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Schema Mapping Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a field-by-field table that lays every source element beside its host target and transform, and turns each element with no faithful home into a visible row.
Independent corroboration: The frozen evidence defines Schema Mapping Table as 'A field-by-field table that lays every source element beside its host target and transform, and turns each element with no faithful home into a visible row', so its operative form is Representation, Specification & Plan.
Nearest alternative: Record, Log & Register — Schema Mapping Table includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: A source-field, target-field, and transformation table is a canonical database migration and data-integration artifact. NIST schema interoperability work supports the source-target semantics, and Library of Congress conversion mappings show the adjacent crosswalk lineage; unmapped fields remain explicit rather than silently dropped.
Related originating lineages:
- Data Science & Analytics — data_science contributes measurement, dashboards, mapping, and operational analytics to the mechanism's formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
- Library & Information Science — Schema Mapping Table's terminology and operating form—a field-by-field table that lays every source element beside its host target and transform, and turns each element with no faithful home into a visible row—are rooted most directly in library and information-science stewardship.
- Organizational & Management Science — organizational_management contributes ownership, decision rights, operating routines, and institutional learning to the mechanism's formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
Review resolution: The blind reviewers disagreed on primary lineage (computer_science versus library_information_science); authoritative or primary research supports computer_science as the best historical origin. A source-field, target-field, and transformation table is a canonical database migration and data-integration artifact. NIST schema interoperability work supports the source-target semantics, and Library of Congress conversion mappings show the adjacent crosswalk lineage; unmapped fields remain explicit rather than silently dropped. The cited NIST, Attribute Metadata Schema for Interoperability; Library of Congress, MODS Conversions and Mappings directly supports the defining operation used in that choice. All independently supported contributing domains are retained without an arbitrary cap, while domain_reach=specialized records later applicability separately from provenance.
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:
- NIST, Attribute Metadata Schema for Interoperability
- Library of Congress, MODS Conversions and Mappings
Notes¶
[n1] A metadata crosswalk is a table of correspondences between the fields of two schemas (e.g., Dublin Core to MARC), used in libraries and data integration precisely to make field-level mapping — and the fields with no counterpart — explicit and reviewable. ↩