Category: Metadata Standards

Crosswalk

Also known as: metadata crosswalk, metadata mapping

Simply put

A crosswalk is a mapping that shows how the elements of one metadata standard correspond to the elements of another. It lets systems and organizations exchange and understand information described under different standards. This helps records, resources, and their descriptive information remain usable when moved or shared between different systems.

Formal definition

In recordkeeping and information management, a crosswalk is a documented mapping of specific elements in one metadata standard to the corresponding elements in another standard, supporting interoperability and the exchange of resources and their descriptive metadata across systems. Crosswalks typically address element-to-element correspondence and may involve partial, approximate, or one-to-many mappings, since standards do not always align exactly; the completeness and fidelity of a mapping depend on the standards involved and the intended use. This entry addresses the metadata sense of the term as used in information management and should not be confused with unrelated everyday meanings (for example, a marked pedestrian crossing).

Why it matters

Records and their descriptive metadata rarely stay in one system for their entire lifecycle. As information is migrated between platforms, shared with partner organizations, or transferred to an archive, the metadata describing it must remain intelligible under a different descriptive scheme. A crosswalk provides the documented correspondence that makes such exchange possible, helping to preserve the usability of records and resources when they move across system or organizational boundaries. Without a reliable mapping, descriptive information can be lost, misinterpreted, or silently dropped, which can undermine the ability to locate, contextualize, and rely on records over time.

The value of a crosswalk is bounded by the fidelity of the mapping it expresses. Because metadata standards are designed for different purposes and do not always align exactly, a crosswalk may capture only partial or approximate correspondences, and some elements in one standard may map to several in another or to none at all. Practitioners should therefore treat a crosswalk as a working instrument whose completeness depends on the standards involved and the intended use, rather than as a guarantee of lossless translation. Understanding where a mapping is exact and where it is approximate is often as important as the mapping itself, since gaps can affect the reliability and usability of the resulting descriptions.

The term also carries a scope caution worth stating plainly. In information management, crosswalk refers to metadata mapping; it should not be conflated with unrelated everyday meanings, such as a marked pedestrian crossing. Keeping the recordkeeping sense distinct helps avoid confusion in documentation, procurement, and cross-disciplinary discussion.

Who it's relevant to

Records managers

Records managers overseeing system migrations or transfers rely on crosswalks to ensure that descriptive metadata remains usable when records move between systems. Understanding where a mapping is only partial or approximate helps them anticipate loss of descriptive detail and plan remediation.

Archivists

Archivists who receive records and their metadata from originating systems use crosswalks to reconcile incoming descriptions with the descriptive standards used in the archive, supporting continued usability and context after transfer.

Metadata and interoperability specialists

Those responsible for metadata standards and system integration design and maintain crosswalks to enable exchange across platforms. They are typically concerned with documenting element-to-element correspondence, including one-to-many and approximate mappings, and with recording the limits of each mapping.

Information governance officers

Governance leads accountable for the coherence of information across systems benefit from crosswalks when assessing whether metadata will remain intelligible during sharing or migration, and when evaluating the risks introduced by gaps between standards.

Inside Crosswalk

Source scheme

The originating metadata schema, classification, or vocabulary whose elements are being mapped. In recordkeeping contexts this is often a retention schedule, classification scheme, or metadata standard from which values or fields are drawn.

Target scheme

The destination schema, classification, or vocabulary to which source elements are mapped. Depending on the project this may be a receiving system's data model, an archival descriptive standard, or another organization's classification structure.

Element mappings

The documented correspondences between individual fields, terms, or categories in the source and target. Mappings are frequently expressed as one-to-one, one-to-many, or many-to-one relationships, and may be exact, broader, narrower, or approximate.

Transformation and translation rules

Instructions describing how values must be reformatted, concatenated, split, or otherwise converted when moving from source to target, particularly where the two schemes structure or encode information differently.

Gaps and exceptions

Documentation of source elements that have no target equivalent, target elements with no source, and cases requiring manual handling or default values. Recording these gaps is important for assessing the completeness and risk of the mapping.

Scope and provenance notes

Metadata about the crosswalk itself, typically including which schemes and versions it covers, who prepared it, and its intended purpose. This context helps users judge whether the crosswalk is fit for a given migration, integration, or interoperability task.

Common questions

Answers to the questions practitioners most commonly ask about Crosswalk.

Is a crosswalk the same as a data migration or conversion process?

No. A crosswalk is a mapping that establishes correspondences between elements of two or more metadata schemas, classification schemes, or vocabularies. It is a specification or reference artifact, not the act of moving records from one system to another. Migration and conversion may rely on a crosswalk to guide how values are translated, but the crosswalk itself defines the relationships rather than performing the transfer. Confusing the two can lead to treating a mapping document as if it were a complete migration plan, which typically also requires validation, testing, and handling of data that does not map cleanly.

Does a crosswalk guarantee that meaning is preserved perfectly between two schemas?

Not necessarily. Crosswalks often involve elements that do not correspond exactly, so mappings may be approximate, partial, or one-directional. Some elements in a source schema may have no equivalent in the target, and some target elements may have no source. Semantic differences, differing granularity, and differing definitions can all introduce loss or ambiguity. For this reason, crosswalks are generally documented with notes about the fidelity of each mapping and about elements that cannot be reliably matched, rather than assumed to be lossless.

How should unmapped or partially mapped elements be handled when building a crosswalk?

In many implementations, elements that lack a clean equivalent are documented explicitly rather than silently dropped. Common approaches include recording the element as unmapped, noting where a target field only partially captures the source meaning, and deciding on a case-by-case basis whether to omit, combine, or approximate values. Documenting these decisions supports transparency and helps later reviewers understand where correspondences are exact and where they are approximate.

Should a crosswalk be treated as a one-time deliverable or an ongoing artifact?

Crosswalks often need maintenance, because the schemas, classification schemes, or vocabularies they connect may change over time. When either the source or target is revised, the mapping can become inaccurate. Many organizations treat a crosswalk as a versioned, maintained artifact, reviewing it when connected schemas are updated and recording the version of each schema the mapping applies to.

What documentation typically accompanies a usable crosswalk?

Beyond the element-to-element mappings themselves, a crosswalk is generally more reliable when it records the schemas or vocabularies being connected and their versions, the direction of the mapping, notes on mappings that are partial or approximate, handling rules for unmapped elements, and any transformation logic applied to values. This supporting documentation helps others interpret and reuse the mapping and understand its limitations.

Can a single crosswalk serve mapping in both directions between two schemas?

Sometimes, but not always. A mapping that works from a source schema to a target does not automatically work in reverse, because correspondences may be asymmetric. An element that maps to a broader target field may not map back to the same specific source element. Where bidirectional use is intended, it is prudent to verify and document the mapping in each direction separately rather than assuming a single mapping is reversible.

Common misconceptions

A crosswalk guarantees a lossless, exact translation between two schemes.

Crosswalks often involve approximate matches, one-to-many relationships, and elements with no equivalent on the other side. Some meaning or granularity is frequently lost or requires judgment, which is why documenting gaps and exceptions is typically part of the exercise.

A crosswalk is a one-time deliverable that stays valid indefinitely.

Because it maps specific versions of source and target schemes, a crosswalk can become inaccurate when either scheme changes. It generally needs to be reviewed and maintained, and its version and scope should be recorded so users know what it applies to.

A crosswalk and a data migration are the same thing.

A crosswalk is the documented mapping between schemes; migration is the process of moving records or data. The crosswalk typically informs or drives a migration, but the mapping itself is distinct from the transformation and transfer activity that acts on actual records.

Best practices

Record the specific schemes and their versions being mapped, along with the crosswalk's intended purpose, so future users can judge whether it remains fit for their task.

Explicitly document unmapped source elements, unmatched target elements, and cases requiring manual handling rather than implying that every element has a clean equivalent.

Characterize each mapping relationship (for example one-to-one, one-to-many, or approximate) and note where meaning or granularity may be lost.

Capture transformation and translation rules for values that must be reformatted, split, or combined when moving between schemes.

Review and update the crosswalk whenever either the source or target scheme changes, treating it as a maintained artifact rather than a one-time deliverable.

Validate the crosswalk against sample records before relying on it for a full migration or integration, and retain the crosswalk itself as evidence of how mappings were derived.