Semantic Interoperability: When Systems Share the Meaning of Data

Preserving Meaning Across Systems

The European Interoperability Framework of 2017 considers both the meaning and the representation of information.[1] The status value released in the following exchange example shows how far readable characters can be from a shared statement.

Example: The Release Status of a Batch

In an illustrative exchange, a production system transmits a batch with the status released. The quality system also has a value released. Technically, the mapping appears unambiguous. In domain terms, however, different conditions may underlie it.

In the production system, the status may mean that all manufacturing steps have been completed. In the quality system, it denotes formal batch release following review of all results. A planning system might interpret the same term as “available for further processing.”

Semantic interoperability therefore requires more than the shared text value. The model must clarify:

• which type of release is meant,
• which object and version the release concerns,
• who or which role granted it,
• which prerequisites had to be met,
• at which point in time the status applied, and
• whether it was subsequently replaced, restricted, or revoked.

Only with this context can a receiving system decide whether the state is suitable for its own task. A technical interface transports the information. The semantic model makes its domain meaning understandable.

An Identically Spelled Status Is Not Yet a Mapping

In the exchange example, released from the production system must not become quality release in the target system merely because the spelling matches. The initial mapping must preserve the actual statement: “manufacturing completed.” Only additional, appropriate evidence could support a different decision.

If the target model offers only “released” or “on hold,” a necessary distinction may be missing. The mapping must identify this loss or return the case for clarification. A forced assignment would change the information.

Every mapping rule needs a source and target definition, scope of applicability, and version. If a system changes the meaning of its status value, the rule must be reviewed again, even if the field name and data type remain identical.

Identities Must Be Stable and Mappable

Shared meaning requires unambiguous references. If two records concern the same batch, the systems must be able to recognize that both identifiers denote the same real object. Without this mapping, duplicates or separate partial views of an otherwise connected operation arise.

A global identifier is not always required. Local identifiers may suffice if their namespace, issuer, and scope are unambiguous. What matters is that coincidentally identical strings are not used to confuse different things and that deliberately different identifiers can be mapped to the same object.

RDF uses Internationalized Resource Identifiers, or IRIs, as globally unique identifiers in a graph data model. An IRI can refer to a documented definition and thus make a concept's intended reference visible.^[2] This is a powerful technical principle, but it still does not replace maintenance of the underlying definition.

For operational data, identities must remain stable throughout their lifecycle. Renaming must not silently create a new object. A merge must document which previous identifiers are affected. For versioned master data, it must remain clear which version applied at the time of an action.

Vocabularies, Code Lists, and Reference Data

Semantic interoperability is often prepared through controlled vocabularies, taxonomies, code lists, and reference data. They reduce labels open to interpretation and establish agreed values.

A code list can define permissible units, test types, or status values, for example. A vocabulary defines which terms are used for objects and relationships. Reference data provide shared mappings, such as market identifiers, material classes, or organizational units.

The European Interoperability Framework explicitly names taxonomies, controlled vocabularies, thesauri, code lists, and reusable data structures as key prerequisites for semantic interoperability.^[1]

Simply publishing a list is insufficient. Each entry needs an understandable definition, an owner, a scope of applicability, and a versioning approach. It must also be clear how systems handle obsolete, replaced, or locally extended values.

A code such as REL can be technically stable. Without a definition, however, it remains unclear whether it means “released,” “submitted for release,” or “released for a particular market.” The semantics lie not in the short code but in the jointly accepted description and its application.

The Decision Needs Relationships to Its Reference Objects

A release status without a reference object leaves open what was decided. In the exchange example, at least the affected batch and the type of decision must be distinguished. Depending on the purpose, version, time, and restrictions are added. A data model records how this information belongs together.

Knowledge Graphs can represent such relationships; RDF provides a graph data model for this purpose.[2] Technically combining graphs does not, however, resolve conflicting uses of the same status term. Domain mappings remain necessary.

Formalization Can Express the Agreed Distinction

Ontologies can formally describe classes and relationships. OWL 2 provides statements about class relationships and disjointness, among other features.[3] This can help explicitly distinguish different types of decisions in the model.

Formalization does not replace agreement between the parties. Both sides must actually use the chosen meaning. Otherwise, a conflict is merely stored more precisely without being resolved in the exchange.

Shared Formats Are Not Enough

CSV, XML, JSON, RDF, or a standardized event log can define how data are represented. That alone does not clarify what a field denotes. The value 12 could be a quantity, a duration, a temperature, or a measurement value. Even if the data type is known to be a decimal number, the unit, measurement method, reference object, and time remain open.

Identical field names are not reliable evidence of meaning either. batch can mean a production batch, a material batch, an import run, or a technical processing unit. Conversely, lot, charge_id, and production_batch can denote the same domain concept in different systems.

When implemented correctly, agreements about format and meaning help detect and prevent transmission and interpretation errors. They do not rule out such errors across the board.

XES and OCEL also structure event data in different ways. Whether two parties understand an event type, object type, or attribute in the same way must be agreed in domain terms, independently of the chosen format.

Testing Exchange Rules Against Jointly Agreed Cases

A shared test should include completion of production without quality release. The expected outcome is that the target system does not infer quality release from it. Another case transmits the appropriate decision with a complete reference; a third leaves the decision type unspecified and must be handled accordingly.

Structural checks can additionally verify required information. SHACL checks RDF data against formulated conditions.[4] Beyond this, the agreed expected results of the exchange cases show whether a mapping preserves the substantive content.

When status definitions or target models change, these cases become relevant again. A merely technically successful import might overlook a change in meaning.

Four Levels Must Fit Together

Interoperability is more than a working interface. The European Interoperability Framework of 2017 distinguishes legal, organizational, semantic, and technical interoperability. The following guiding questions apply this distinction to operational data exchange.

The EIF does not treat the syntactic level as a fifth or alternative main level: structure and format are an aspect of semantic interoperability there. The legal level, by contrast, is explicitly part of the model. Data that can be transmitted technically and understood in domain terms are not thereby permissible for every purpose.

The levels do not build on one another as rigid stages. They influence one another. A domain definition can require additional fields to be transmitted. An organizational change can alter an existing status concept. A technical limitation can cause relevant relationships to be lost during export.

Governance Preserves Meaning Over Time

Semantics is not a one-time data project. Concepts change, processes are adapted, organizations introduce new systems, and regulatory requirements evolve. Semantic interoperability therefore needs ongoing governance.

This governance includes owners for vocabularies and reference data, documented change procedures, versions, approvals, and deprecation rules. Consumers must be able to identify which version of a model a dataset uses and how long an older version will be supported.

Examples and test data matter too. A definition can appear linguistically unambiguous yet be implemented differently. Shared conformance tests show whether sender and receiver actually handle boundary cases in the same way.

Domain responsibility remains distributed. Technical teams can implement formats and transformations. Domain owners must assess meaning, permissible use, and the effects of changes. Without this connection, integration can be formally sound but operationally unreliable.

What Semantic Interoperability Does Not Guarantee

• Shared concepts do not guarantee correct data. A value can be semantically unambiguous yet incorrectly recorded.
• Validation does not prove real-world truth. It checks data against formulated rules.
• Interoperability is not a blanket demonstration of compliance. Legal, regulatory, and organizational requirements still need separate review.

The Receiver Must Be Able to Recognize the Same Decision

In the release example, an unchanged string would be a poor result if the target system inferred a different permission from it. Explicitly rejecting an unclear case, by contrast, can be the correct substantive response.

The benchmark therefore lies in the receiver's behavior: Which object and statement does it recognize, which use does it permit, and which information is missing? Definitions, mappings, and shared tests make these questions verifiable.