How do I review source mappings before an ontology drives operations?

Identify the claim hidden in a renamed column

A fictional integration maps a supplier’s ready_date to an internal field called available_at. The import succeeds and every value is a valid date. Yet the supplier meant ready for collection at its dock, while the planner interpreted ready for use at the maintenance site. The error lies in meaning, not parsing. Begin the review with the decision that will consume the field.

Separate identity from the display label

Check whether an identifier is stable, unique in its actual namespace, and ever reused. Include the source system and scope needed to distinguish records. Two rows labeled “Pump 12” may identify a physical asset, a position, or a maintenance template. A name-based merge can erase exactly the distinction the operating workflow needs to preserve.

Review units and time as first-class inputs

Record the unit and transformation for every decision-relevant quantity. Distinguish when an observation was valid from when it arrived and when the mapping ran. Ask what happens when a source corrects yesterday’s value today. Updating a current display may be reasonable; silently replacing the evidence attached to yesterday’s decision is a different operation.

Use a mapping review card

Field	Review evidence
Source and owner	Who can explain or correct the claim?
Target meaning	Which decision may rely on the result?
Identity scope	What makes two records the same object?
Transformation revision	Which conversion produced this value?
Time and unit	What interval and quantity does it represent?
Conflict behavior	Reject, quarantine, qualify, or escalate?

Retain both an ordinary record and a counterexample with the card. The reviewer should be able to show why the two records receive different treatment.

Test disagreement without forcing a winner

Provide two conflicting observations, a missing unit, a reused ID, and an old record arriving late. Ask whether the mapping can preserve those conditions. A pipeline that always emits one confident value may be simpler to query but can destroy important uncertainty. Where the decision requires a trusted value, stop that decision and make the unresolved condition visible.

Preserve the path to correction

Keep enough lineage to identify which transformation and source records contributed to an operational result. Bound access to that lineage according to the underlying data sensitivity. When a mapping changes, locate affected consumers and historical outputs before promoting it. The acceptance criterion is not the percentage of fields populated; it is whether the mapped evidence supports the promised decisions and can be corrected responsibly.

Evidence and scope

• W3C SKOS Reference: SKOS distinguishes exact, close, broader, narrower, and related mappings between concepts.
• W3C PROV-O: PROV-O represents entities, activities, agents, and derivation relationships.

The proposed checks are teaching tools; validate their behavior in the actual environment.