Skip to content

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.[1]

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.

References

[1] 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. ↩