Same Field Name, Different Business Events: The Semantic Gap in Data Integration

A cross-system report finally runs: both source systems have a "completion time" column. Engineers map the fields, and numbers display correctly. Yet during business review, the same case shows different durations. The issue is not the interface or calculation formula. One system records when staff clicks "complete"; the other records when the result notification is delivered. The field name is identical, but the underlying business event differs. Data is connected, but meaning is not aligned.

Field Names Are Only the Starting Point

Cross-system integration typically checks field names, types, and value ranges. These ensure data transmission but cannot guarantee two columns are comparable. Beyond "completion time," similar ambiguities appear in seemingly ordinary terms like "valid," "in progress," or "acceptance count."

Take "acceptance count": one system counts items newly entering the process today; another counts items confirmed by the counter today. Both numbers may be accurate, but the difference stems from the business node. Merging them into a single trend line produces a conclusion based on mixed definitions, not a pure data error.

The National Data Bureau's public standard interpretation calls for business metadata standards for structured data to address data-to-scenario correspondence, data semantics, and logical relationships. This shows field explanations are not mere interface documentation footnotes; they are part of whether data can be correctly used.

The Most Easily Lost Context: Conditions Under Which a Value Is Produced

After a value leaves its source system, it often retains its name, format, and update timestamp, but the conditions of its creation may not travel with it: who wrote it at which node, whether later corrections are allowed, whether a null means "not applicable" or "not yet filled," and whether the statistical scope excludes withdrawn items.

Suppose a shared interface returns "status=completed." The consumer uses it to calculate service duration. If the provider's "completed" means internal processing ended, while the consumer wants to measure when the public receives the result, the report — no matter how fast — answers the wrong question.

This does not mean every field needs a long specification. More useful is to keep the few things that can change judgment alongside the data: business definition, generation node, applicable scope, update and correction rules. These four items are a synthesis of public references and common data integration problems, not a regulatory template.

Data Quality Cannot Be Judged Only by "Absence of Wrong Values"

The Regulations on Government Data Sharing (State Council Order No. 809) requires agencies to establish a full-process quality management system and strengthen standardized management across collection, storage, processing, transmission, sharing, and use. It also requires sharing applications to specify usage scenarios and scope. While it does not dictate specific field calibrations for the hypothetical scenario, these requirements remind us that quality must be evaluated within the actual usage chain.

Interface success, non-null fields, and valid formats prove only part of quality. If a value is used to answer a question it was never fit to answer, technical checks pass but business judgment still goes astray. W3C's DCAT 3, from a data catalog interoperability perspective, states that metadata describing datasets and data services aids cross-catalog discovery and use; it is a technical reference and cannot replace concrete business calibration confirmation.

Therefore, the real question in data sharing projects may not be "how many fields remain unconnected" but "do the fields that key conclusions depend on have explanations both parties accept?"

From "Can Transmit" to "Can Trust and Use"

For product design, a field mapping table that only records "field A maps to field B" leaves future maintainers unaware why the mapping holds. A safer approach is to make important fields' business definitions and version changes visible; when the source system adjusts rules, downstream reports know which conclusions need re-verification.

For business users, seeing two numbers disagree does not require immediately labeling one as "dirty data." First ask whether they describe the same object, the same event, the same time range. This question seems slow but prevents stitching accurate data from different calibrations into a wrong judgment.

As data sharing deepens, the bottleneck often shifts from "cannot connect" to "cannot explain clearly." Connecting the interface is the starting point; letting numbers retain an understandable provenance after leaving their original system is what truly lets them enter business judgment.

Sources and References

Regulations on Government Data Sharing , State Council Order No. 809, key references Articles 18 and 20.

Promoting High-Quality Data Resource Circulation and Utilization with High-Quality Data Governance Standards , National Data Bureau website, March 28, 2025. Business metadata and semantics expressions are from this public interpretation.

Data Catalog Vocabulary (DCAT) — Version 3, W3C Recommendation, 2024. Used only as a technical reference for data catalog interoperability.