Semantic Interoperability: How to Ensure Two Organizations Understand Data in the Same Way

Two organizations sign a data-sharing agreement, configure their connectors, sort out their certificates and ensure that files move from one system to another without errors. Technically, everything works. And yet, when someone analyses the received data, they discover that a supplier’s “delivery date” field does not mean the same thing as the customer’s “delivery date” field: one records when the order leaves the warehouse, while the other records when it arrives at its destination. The connection is there, but the meaning has been lost along the way.

This problem has a name: semantic interoperability. It refers to the ability of two systems to interpret a piece of data in exactly the same way, beyond simply being able to transmit or read it. It differs from technical interoperability, which addresses how data is transported, and syntactic interoperability, which addresses the format in which data is structured. When the semantic layer is missing, each team interprets the same data according to its own internal conventions, and any decisions based on it carry that error forward, often without anyone noticing until it is too late.

For data architects, governance managers and integration specialists working on collaboration projects between organizations, this is not a theoretical problem. It is one of the most common reasons why dashboards do not add up, aggregated reports from several companies contain hidden errors, and data-sharing projects lose the trust of the very people who should benefit from them.

What Is Semantic Interoperability, and Why Is Connecting Systems Not Enough?

Semantic interoperability requires prior agreement on the meaning of each data element: what it measures, which unit it uses, its level of precision, when in the process it is recorded and under what conditions. This agreement does not arise spontaneously between two organizations that have never formally aligned their definitions, because each has developed its own data model independently, in response to its internal needs.

The usual result is that two fields with the same name mean different things, or that two fields with different names mean the same thing. Both situations are dangerous, but the first is more deceptive because nobody suspects an error until the numbers fail to add up.

Solving this requires three components working together:

• Shared data vocabularies, which establish terms and their precise definitions.
• Ontologies, which describe the relationships between those terms and the contexts in which they make sense.
• Common data models, which translate this conceptual agreement into concrete technical structures, such as schemas, fields and data types.

Without these three layers, any data exchange between different organizations becomes, at best, a constant process of manual translation and, at worst, a source of errors that nobody detects in time.

Real-World Examples of Semantic Misunderstandings

Semantic misunderstandings are rarely dramatic. They are small, silent and cumulative, which makes them harder to detect than an obvious technical failure.

Unspecified Units of Measurement

An agri-food cooperative in Castile and León receives a “weight” value for each shipment from a logistics provider. The provider records it in kilograms, while the cooperative, based on its internal conventions, assumes it refers to tonnes when integrating the data into its planning system. The discrepancy goes unnoticed until warehouse capacity calculations begin to fail to add up over several weeks. By then, purchasing decisions have already been made based on incorrect figures.

Date Formats and Meanings

A local authority and an urban services company share incident data. One system records the “resolution date” as the moment when the administrative case is closed; the other records it as the moment when a technician completes the on-site intervention. Both fields have the same name and appear to represent closing dates, but they measure different milestones in the process. Response-time indicators calculated by combining the two sources become distorted, even though the error is not apparent from a simple inspection of the data.

Categories That Do Not Mean the Same Thing

A distribution company classifies its products as “perishable” and “non-perishable” and shares this categorization with a business partner. In its own system, the partner uses the same “perishable” label but applies a different shelf-life criterion. For example, it includes products with a shelf life of up to six months, while the first company only includes products with a shelf life of less than thirty days. The data exchange appears correct because the values match textually, but the meaning behind each category is different, and any joint inventory analysis inherits this ambiguity.

These three examples share a common pattern: the error is not in the data itself, but in the lack of an explicit agreement on what the data represents.

How a Data Space Helps Prevent These Problems

A modern data space does not automatically solve semantic interoperability, but it provides the infrastructure needed for participating organizations to reach an agreement and maintain it over time.

Shared Vocabularies in the Federated Catalogue

The metadata broker acts as a federated catalogue for the organizations participating in the data space. Each published dataset is described using structured metadata that specifies not only where the data is located and who provides it, but also what each field means, which unit it uses and under what conditions it was generated. By exporting this metadata in a standard such as DCAT-AP-ES, organizations are required to document their information using a shared vocabulary rather than relying on their own implicit terminology.

This does not eliminate the diversity of internal data models — each organization continues to work with its own systems — but it requires the translation between the internal model and the common model to be made explicit when the data is published. This is precisely the point at which meaning was previously lost.

Ontologies and Data Models as a Technical Contract

While a vocabulary defines terms, an ontology describes how they relate to one another and the contexts in which they apply. It is not enough to agree that “delivery date” is a date field; it is necessary to specify whether it refers to departure from the warehouse, transit or receipt of the goods. These relationships, made explicit through identifiers and links using a linked data approach, allow two different systems to reason about data consistently, rather than merely transmit it.

The final step is to translate vocabularies and ontologies into technical data models: concrete schemas that define fields, types, formats and constraints. This shared model acts as a contract: any organization publishing a particular type of data knows which structure to follow, and any organization consuming it knows what to expect, without needing ad hoc bilateral agreements with every new partner. The data space’s policy engine and transfer module rely on these common models to validate that the data being exchanged complies with the agreed structure and meaning.

An Example from Castile and León

Imagine an agri-food company in Castile and León that needs to share raw material quality data with several suppliers in the region. Without a common vocabulary, each supplier sends quality certificates using its own criteria, scales and units. The company’s quality team must then manually standardize every submission before it can compare them.

By joining a data space with a shared vocabulary and data model for “raw material quality”, suppliers can publish their information using the same structure and definitions. The quality team no longer needs to manually translate each source and can compare deliveries from different suppliers with confidence that the same field means the same thing in every case. The savings are not limited to technical integration time; they also come from reducing interpretation errors that previously went unnoticed.

Where to Start

Achieving semantic interoperability is not a one-off project that can be completed and forgotten. It requires ongoing governance: reviewing vocabularies as new use cases emerge, keeping ontologies up to date and ensuring that data models evolve in a coordinated way across all participating organizations.

A regional data space provides a framework for this shared governance by bringing interested organizations together around common catalogues, vocabularies and models that none of them would have an incentive to maintain on their own.

If your organization needs to share data with suppliers, customers or public administrations and wants to prevent semantic misunderstandings from undermining its analyses and decisions, a modern data space provides the infrastructure and technical support needed to establish this shared understanding from the very first exchange. Find a technology partner with experience in data spaces to explore how to get started.