Does a common file format guarantee shared meaning?

No. Field definitions, units and code meanings still need agreement.

Is exchange always real-time?

No. It can use periodic files, requests or other timing arrangements.

Does receiving data mean it has been fully integrated?

No. Further mapping, reconciliation and validation may be required.

AI Glossary / Data engineering and architecture / Advanced

Data exchange

Definition

Data exchange is the transfer of information between systems or organizations in a form the receiving side can interpret and use. It involves more than moving bytes: the participants need compatible representations and a shared understanding of relevant meanings. Exchange can occur through files, messages, APIs or other interfaces, with details determined by the purpose and the systems involved.

What it means

A file can arrive intact and still be misunderstood. A field named Amount might use different units, a date may follow an unfamiliar convention or a code may have different meanings in the two systems. Successful exchange therefore includes agreement about the content as well as its delivery. For an AI workflow, receiving a dataset is only a starting point; the receiving process must know which fields and versions it is using and what the transferred values actually represent.

How it works

The participants define the information to exchange, its representation and the way it will be transmitted. The sender produces data according to that agreement, and the receiver checks and interprets it. Metadata can explain fields, provenance, quality and versioning. W3C's Data on the Web Best Practices documents these concerns for Web data publication and reuse. The exact mechanism may be a scheduled file or a request-based service, but a readable format alone does not resolve semantic differences or establish that every expected record was included.

Three practical examples

A supplier sends an order file whose product identifiers and quantity units match the buyer's documented expectations.
A research team publishes a dataset with field descriptions and version information so another team can interpret it.
An application receives reference records through an API and checks the schema version before applying its existing mapping.

Think of it this way

Imagine sending a recipe to another kitchen. The page can arrive perfectly, yet the result may differ if one cook interprets a cup differently or misses an instruction about temperature units. A common document format solves only part of the problem. Data exchange similarly needs enough shared context to preserve meaning. Confirming delivery is useful evidence, but the receiver also needs to understand what was sent and how it fits the intended task.

Worked example

Consider an original hypothetical exchange containing two order lines: quantity 2 and quantity 3, both explicitly measured in boxes. The receiving system stores individual items, and the agreed product mapping states that each box contains 12 items. The correct converted quantities are 24 and 36, totaling 60 items. If the receiver imports the raw numbers as items, it records a total of 5 instead. The file can be syntactically valid in both cases; the difference is interpretation. This example assumes the same documented pack size for both lines. Different products or changing pack sizes would require the corresponding mapping information rather than one universal multiplier.

Illustrative case study

A fictional distributor replaces a manual spreadsheet transfer with an API. The technical connection succeeds, but a trial reveals that the sender's shipment date and the receiver's expected arrival date are not the same concept. The partners document separate fields and test a sample whose dates differ. They also agree how corrections will be identified. The scenario illustrates why automating transport does not automatically solve semantic alignment. It does not suggest that one interface style is always superior or that every mismatch can be repaired by renaming a field without changing its interpretation.

Common misconceptions and mistakes

Data exchange is not identical to data integration. Exchanged data may still need further reconciliation before it can support a combined analysis. A standard format such as JSON or CSV does not automatically provide common definitions. Another mistake is treating successful delivery as proof of completeness or accuracy. Missing records, unsupported versions and unit mismatches can survive a technically successful transfer. Finally, the fact that two systems can exchange information does not establish permission for every possible use of it; the intended scope must be understood separately.

Business use

The concept helps teams define practical expectations at organizational and system boundaries. Specify the information, units, identifiers, update timing and handling of corrections before relying on a transfer. Test a small sample with known results, including values that expose likely misunderstandings. Record which version was received so later analysis can be traced to its inputs. For an AI project, retain the context needed to interpret external data instead of presenting delivery success as evidence that the dataset is ready for every proposed application.

Check your understanding

How many individual items did the toy order contain?

Answer: Sixty.

Why would importing the raw quantities give the wrong total?

Answer: The sender measured boxes while the receiver expected items.

What assumption supported the conversion?

Answer: Both lines used the documented twelve-item pack size; that rule should not be applied blindly to unrelated products.

Related terms

Interoperability
Schema
Metadata
serialization
data integration
API

Learn next

Write a short exchange agreement for a small dataset. Include field meanings, units, identifiers, version information and expected timing. Then create a test record that would be misread if one assumption were omitted. Use the result to improve the agreement before scaling up the transfer.

Sources

World Wide Web Consortium, Data on the Web Best Practices: https://www.w3.org/TR/dwbp/ The boxes-to-items calculation, recipe analogy and distributor case are original educational illustrations. The W3C reference supports the importance of metadata and interoperable representation in Web data reuse; this entry does not claim that one publication specifies every private-system exchange protocol.

Previous: Data event Next: Data exfiltration