Metadata integration moves descriptions and relationships between systems that may organize them differently. Start with a documented mapping and a small test collection. Identify what the receiving system can represent, what must change and what requires an explicit exception.
Map the meaning before moving the value
The original context of metadata integration includes catalogs, databases, reporting tools and content repositories. In each case, identical field names can describe different events. A date called “updated” might mean a substantive revision in one system and the most recent import in another.
Use a source owner and a receiving-system owner to agree the mapping. DCMI Metadata Terms distinguishes concepts such as identifier, modified and subject. A local crosswalk should identify which concepts it adopts and which fields have organization-specific meanings.
Record cardinality, allowed values, blank-value meaning, transformation and provenance for every mapped field. Cardinality describes whether one or several values are allowed. A target that permits only one subject cannot silently preserve a source with three subjects.
Write a small explicit crosswalk
| Source field | Target field | Rule |
|---|---|---|
| id | identifier | Copy exactly as text; retain leading zeros. |
| title | name | Require nonempty text; preserve wording. |
| subjects | topic_codes | Keep the complete array; reject unknown codes. |
| modified | modified_date | Require YYYY-MM-DD; retain substantive-change meaning. |
| language | language_tag | Use the sample profile’s allowed values en or fr. |
| owner | owner_ref | Map a known source team to a target team ID. |
| note | note | Preserve an explicit null separately from empty text. |
The sample also records the source system and mapping version. Keep source creation, source modification and transfer timestamps separate when your real workflow needs all three. Document whether ordering in a repeated field matters.
Inspect a transfer with rejected records
Download the tested mapping example and crosswalk CSV. The ZIP includes source JSON, a standard-library Python 3.10+ transformer, expected results, tests and instructions. It uses a deliberately small local profile; its en/fr and topic-code lists are examples, not a complete language or subject registry.
Check completeness and meaning independently
- Validate source structure and identify duplicates before transforming.
- Run the mapping into a separate output area; retain the received source.
- Reconcile accepted and rejected records to the input count and IDs.
- Compare repeated values, nulls, identifiers, dates and relationships in representative records.
- Resolve exceptions with the source owner; rerun the corrected input and preserve the decision trail.
- Import a bounded sample into the real destination and test how its interface, search and export represent the mapped fields.
The supplied tests reject duplicate IDs and confirm the two intentional exceptions. After correcting their source values, all four records map. This proves the example's rules; it does not certify any commercial connector or receiving system.
For unchanged values, equality checks are useful. For transformed values, compare the agreed semantics. A successful API response and a matching item count leave field-level loss unresolved.
Plan ongoing synchronization separately
A one-time transfer has a known input boundary. Ongoing synchronization must decide which system owns each field, how changes are detected and what happens when both sides edit the same item. Define deletion, retirement and missing-record behavior explicitly. An absent export row could indicate filtering or an error rather than an intended deletion.
Version the mapping, keep exception reports and test changes before applying them broadly. If a vocabulary changes, document old-to-new codes and the treatment of retired terms. Link the mapping to the maintained metadata profile and the project's migration acceptance criteria.