Schema Crosswalk Table¶
Mapping table — instantiates Schema Conflict Resolution
A row-per-category table that pairs each source category with its target and records the type of correspondence — exact, partial, one-to-many, or non-equivalent — so a mapping's strength is visible at a glance.
Once two schemas have been elicited and a resolution mode chosen, someone has to write down which category corresponds to which. Schema Crosswalk Table is that artifact: the tabular record where every source category is placed beside its target and, crucially, tagged with the type of correspondence between them. Its defining property is that it is a structured record of correspondence strength, not a flat "maps-to" list — a well-built crosswalk shows at a glance which pairs are exact, which are partial or one-to-many, and which are marked non-equivalent. The table is the reference the whole resolution points back to, but it is a record of correspondence, not the decision that produced it nor the executable transform that applies it.
Example¶
A national statistics agency retires its old occupation classification and adopts a revised one, and every longitudinal dataset now spans both. The crosswalk table has one row per old code. "Computer Programmers" maps exactly to the new "Software Developers" code — a clean one-to-one. "Postmasters and Mail Superintendents" splits: part of it maps to a new "Postal Service" managerial code and part to a general administrative one — a one-to-many, flagged as partial. And an old catch-all "Miscellaneous Technicians" bucket has no honest single target; its row is tagged non-equivalent, with a note that any time series crossing this code must break rather than pretend continuity. Analysts reading the table can see immediately where a trend line is safe, where it needs a splitting assumption, and where it simply cannot be carried across the revision. The table doesn't run the conversion or decide the reclassification — it records, precisely, how the two classifications correspond.
How it works¶
- One row per source category. Each category in the source schema gets a row pairing it with its target category or categories.
- Tag the correspondence type. Every row carries an explicit type — exact, partial, contextual, one-to-many, many-to-one, contested, or non-equivalent — so strength is never inferred from silence.
- Carry caveats and examples. Rows hold short notes and representative examples that make the correspondence type legible without re-deriving it.
- Point outward, not inward. The table references the decision that set the mode and the rules that execute the movement; it is the correspondence record they share, not a substitute for either.
Tuning parameters¶
- Correspondence vocabulary — how many distinct correspondence types the table admits. A richer vocabulary captures nuance but makes the table harder to read and to fill consistently.
- Direction — one-directional (source→target) or bidirectional. Bidirectional tables are more useful but double the rows that must stay consistent.
- Granularity — whether rows sit at the category level or descend to sub-values. Finer rows expose partial mappings but enlarge the table.
- Caveat verbosity — how much note and example each row carries. More context reduces misuse but risks a table too heavy to maintain.
When it helps, and when it misleads¶
Its strength is legibility: a good crosswalk makes the shape of a mapping — where it's clean, where it's lossy, where it's impossible — visible to anyone at a glance, which is exactly what a flat lookup hides. The correspondence-type column is what distinguishes a genuine crosswalk from a naive equivalence list; the practice descends from metadata crosswalks between standards like Dublin Core and MARC.[n1]
Its failure mode is crosswalk theater: a table that looks authoritative because it is complete and tidy, yet was never tested against real cases and never wired to any decision rule. A pristine crosswalk can be confidently, uniformly wrong. The classic misuse is treating the existence of the table as proof the conflict is resolved — shipping it and moving on while nothing downstream actually changes. The guarding discipline is to treat the table as a hypothesis until a case-based test has run its rows against real data, and to keep the non-equivalent rows honest rather than forcing every category to find a partner.
How it implements the components¶
schema_crosswalk— the table is the crosswalk: the structured, row-per-category record pairing source and target.category_correspondence— each row records the specific correspondence and its type (exact / partial / one-to-many / non-equivalent), the heart of the resolution.
It records correspondences but does not decide the resolution mode (integration_decision) — that is Ontology Mapping Workshop — nor turn a row into an executable transform with exception handling (translation_rule, exception_handling_path) — that is Data Mapping Specification.
Related¶
- Instantiates: Schema Conflict Resolution — the shared correspondence record the rest of the resolution reads from and writes to.
- Consumes: Ontology Mapping Workshop — supplies the elicited schemas and the resolution mode this table records correspondences under.
- Sibling mechanisms: Boundary-Spanner Review Session · Case-Based Mapping Test · Data Mapping Specification · Glossary Alignment Table · Ontology Mapping Workshop · Semantic Interoperability Review · Taxonomy Reconciliation Review · Translation Register
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Schema Crosswalk Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a row-per-category table that pairs each source category with its target and records the type of correspondence — exact, partial, one-to-many, or non-equivalent — so a mapping's strength is visible at a glance.
Independent corroboration: The frozen evidence defines Schema Crosswalk Table as 'A row-per-category table that pairs each source category with its target and records the type of correspondence — exact, partial, one-to-many, or non-equivalent — so a mapping's strength is visible at a glance', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Crosswalks documenting exact, partial, and non-equivalent category correspondence are canonical knowledge-organization artifacts.
Related originating lineages:
- Computer Science & Software Engineering — Data integration materially implements one-to-many transformations.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] In library and metadata practice, a crosswalk is a table mapping the elements of one metadata standard to those of another (e.g., Dublin Core to MARC), explicitly noting where elements correspond exactly, partially, or not at all — the origin of the correspondence-type discipline this mechanism inherits. ↩