Why Numbers Don't Connect: The Semantic Interoperability Problem

📍 Where we are: Part III gave the data an organizational backbone — governance, quality, master data; Part IV now asks why, even with perfect plumbing and clean records, numbers from different systems still refuse to line up, and what it takes to make meaning travel.

In the last chapter we built the human and policy scaffolding around data — data governance (who decides the rules), the dimensions of data quality, and master data management (one trusted version of the things the business cares about, like products and materials). Governance can make every system's records clean, owned, and well described, and still leave a maddening problem untouched: when you finally pull two clean datasets side by side, the numbers do not connect. The pipes are perfect. The pump moves water flawlessly. And yet what comes out the other end does not add up.

This chapter is about that gap. It has a name — the semantic interoperability problem — and it is one of the single biggest reasons that, after decades of digitization, biomanufacturers still cannot easily combine their own data. The FAIR principles for scientific data management were formulated in direct response to exactly this difficulty [1].

The simple version

Imagine three people describing the same event. One says "the meeting is at noon," another writes "12:00," a third notes "12h00 GMT." A human shrugs and understands all three. A computer does not. To a machine, "noon," "12:00," and "12h00 GMT" are three unrelated strings of characters — unless someone has told it, formally, that they mean the same instant in time. Semantic interoperability is the work of telling machines, once and for all, when two differently-spelled things are really the same thing.

What this chapter covers

We start by separating two ideas that sound alike — syntactic and semantic interoperability — with a worked example. Then we catalogue the sources of heterogeneity (the many ways the same fact gets recorded differently), show why the obvious fix of "just map them" collapses as systems multiply, and arrive at the first real remedy: controlled vocabularies, shared lists of agreed terms. We finish at the edge of the deeper solution — a shared model of meaning — which is the subject of the next chapter.

Two kinds of "talking": syntax versus meaning

Recall the distinction the connectivity chapter introduced. Interoperability is the ability of separate systems to work together. It comes in layers, and a well-known model — the Levels of Conceptual Interoperability Model (LCIM) — names them, from no/technical interoperability up through syntactic (shared format) and semantic (shared meaning) [6]; later extensions add pragmatic, dynamic, and conceptual levels, giving the mature seven-level model.

Two of those layers matter here. Syntactic interoperability means systems agree on format: the file opens, the message parses, the fields line up. Semantic interoperability means they agree on meaning: both ends know that a value in one system and a value in another describe the same kind of real-world thing, on the same scale, under the same conditions [6]. Syntax moves the bytes. Semantics preserves the meaning. You can have the first completely and the second not at all.

Here is what that looks like in a real plant. Three systems — a process historian (a time-series database such as AVEVA PI System, formerly OSIsoft PI), a manufacturing execution system (MES) such as Emerson DeltaV MES (formerly Syncade), and a laboratory information management system (LIMS) such as LabWare — each record what is, physically, one measurement: the temperature inside bioreactor BR-101. Each describes it differently:

One physical fact, three machine descriptions. Every system here is internally correct; none agrees with the others on name, number, unit, or time format. Figure by the authors.

Every box is valid. Every system is internally consistent and would pass its own data-quality checks. The three timestamps even denote the very same instant — epoch 1718271000, 05:30 EDT, and 09:30Z are one moment written three ways (and note the subtlety: because June 13 falls in daylight saving time, US Eastern is EDT at UTC−4, so the matching wall-clock value is 05:30 EDT; writing it 05:30 EST (the standard-time offset, UTC−5) would silently name an instant an hour later — 10:30Z instead of 09:30Z — exactly the hazard this chapter warns about). Yet a program asked to "find all temperature readings for BR-101" would find none of them automatically, because nothing tells it that TIC101.PV, Temperature, and temp_reactor are the same property of the same vessel — or that 37.0, 98.6, and 310.15 are the same value in Celsius, Fahrenheit, and Kelvin, recorded at one and the same time. The data moved perfectly. The meaning did not.

To make this concrete: a query that genuinely retrieves all three readings would have to encode, by hand, every reconciliation the systems left implicit — something like

MATCH  property IN { TIC101.PV, Temperature, temp_reactor }
  AND  vessel   IN { BR-101, EQ-00457 }
NORMALIZE  unit  ->  degC      // 37.0 = (98.6 - 32) / 1.8 = 310.15 - 273.15
NORMALIZE  time  ->  UTC       // 1718271000 = 2024-06-13 05:30 EDT = 09:30Z

Every one of those clauses is private knowledge that a person had to supply. Multiply this by hundreds of tags and dozens of systems and you have the everyday reality of biomanufacturing analytics — which is precisely what a shared layer of meaning is meant to eliminate.

The many faces of heterogeneity

That single example already hides several distinct problems. Semantic heterogeneity — the umbrella term for the gap, meaning that the same things are conceived and labelled differently across systems and people — comes in identifiable flavours, and naming them is the first step to fixing them [5].

• Naming. The same property wears different labels: TIC101.PV, Temperature, temp_reactor. Conversely — and worse — the same label can mean different things in two systems (one plant's "yield" is mass; another's is a percentage).
• Units of measure. Celsius, Fahrenheit, Kelvin; grams per litre versus milligrams per millilitre. A number without its unit is meaningless, and a number with an implied unit is a trap. This is why standards bodies define the units themselves formally — the ISO/IEC 80000 series fixes the names and symbols of quantities and units — and why machine-readable code systems such as UCUM (the Unified Code for Units of Measure) let a data format carry the unit with the value rather than leaving it in someone's memory.
• Identifier schemes. Is the vessel BR-101, BR101, Bioreactor-1, or asset tag EQ-00457? Two systems can hold rich data about the same physical bioreactor and never realize it, because their names for the thing never match.
• Timestamps and time zones. Epoch seconds, local wall-clock time, and UTC with a Z suffix can all denote the same instant — or, read naively, three different instants. A missing time zone has silently corrupted more analyses than almost any other single defect.
• Granularity. One system logs every second; another stores a one-minute average; a third keeps a single per-batch number. Combining them requires knowing what each row actually represents.
• Implicit context. The deadliest category, because it is invisible. A column called temp might mean the setpoint or the measured value; a result might assume a sample was filtered first. The knowledge that disambiguates it lives in an engineer's head, not in the data.

The FAIR principles — a widely adopted framework for Findable, Accessible, Interoperable, Reusable data — directly address this. Their I, Interoperability, demands that data use shared, formally defined vocabularies and carry machine-actionable meaning, precisely so that the heterogeneity above can be resolved by software rather than by a human who happens to remember the context [1].

Watch out

Clean data is not connected data. A dataset can score perfectly on the quality dimensions from the previous chapter — complete, accurate, consistent within itself — and still be semantically isolated. Quality is about being right; interoperability is about being combinable. They are different problems, and passing one does not pass the other.

Why "just map them" does not scale

The intuitive fix is a translation table: write a converter that turns the Historian's vocabulary into the MES's, another for MES-to-LIMS, and so on. These are point-to-point mappings, and they fail for the same reason point-to-point connections failed in the connectivity chapter — they explode in number.

Resolving meaning pairwise needs a converter for every pair and grows with the square of the systems; mapping each system once to a shared model grows linearly. Figure by the authors.

Map each system once to a shared model, and the n² tangle of pairwise mappings collapses to n. Original diagram by the authors, created with AI assistance.

With n systems, pairwise mapping needs on the order of n² converters; four systems need six, ten systems need forty-five. Each converter encodes one team's private understanding, and each breaks the moment a system is upgraded, a tag is renamed, or a unit convention shifts — which in a living plant is constantly. This is why so much analytics effort goes not into analysis but into wrangling: hand-reconciling names, units, identifiers, and timestamps before any real question can be asked. Mediating meaning through one shared reference model turns that n² tangle into n mappings — each system aligns once, to the shared model, and is then comparable with every other [4]. The economics are the same lesson as connectivity standards, applied one level deeper: not to the wire, but to the words.

A first remedy: reference data and controlled vocabularies

The first practical step toward shared meaning is modest and powerful: agree on the words. Reference data, introduced with master data in the previous chapter, is the set of standard, approved values a field is allowed to take, and a controlled vocabulary is an agreed, governed list of terms with their definitions — so that everyone writes degC, not also Celsius, °C, and centigrade. When a number must be reported in a unit drawn from one official list, two systems can finally be compared without a human in the loop.

International standards supply exactly such vocabularies. ISA-95, standardized as IEC 62264, defines a canonical set of object models and terms for enterprise-to-manufacturing data — what a production request, a material lot, or an equipment element formally is — so that interfaces between business and plant systems share one definition instead of negotiating their own [2]. In the analytical laboratory, the Allotrope Foundation — a consortium whose members include large pharmaceutical companies such as Merck, GSK, and Amgen — maintains shared vocabularies and ontologies (notably the Allotrope Foundation Ontologies, AFO) so that results, and the units, techniques, and identifiers attached to them, mean the same thing regardless of which vendor's instrument produced them, directly attacking the naming, units, and identifier heterogeneity above [8].

But a flat vocabulary — a simple list of approved terms — has a ceiling. A list can tell a machine that degC is an allowed unit; it cannot tell the machine that Celsius and Kelvin are both temperatures, related by a fixed formula, while grams-per-litre is something else entirely. A list of allowed equipment names cannot express that a bioreactor is a kind of vessel, which is part of an upstream suite, which participates in a fermentation. The relationships between terms — is a kind of, is part of, participates in — carry as much meaning as the terms themselves, and a flat list has nowhere to put them [5]. To capture relationships, you need not a list but a model.

The promise: a shared model of meaning

That model is an ontology: a formal, machine-readable specification of the concepts in a domain and the relationships among them — a shared map of what exists and how it connects [5]. In practice these models are written in the W3C's Web Ontology Language (OWL), built on RDF and serialized in formats such as RDF/XML or the more readable Turtle, so that the meaning is expressed in a standard a computer can load and reason over. Where a vocabulary lists words, an ontology states facts a computer can reason over: a bioreactor is a kind of equipment; a temperature reading is a measurement of a temperature; Celsius and Kelvin measure the same quantity. Once those facts are written down formally, software can do what the human did effortlessly at the start of this chapter — recognize that three different descriptions point to one reality — without a human in the loop.

To keep separate ontologies mutually compatible, the field anchors them to a shared top-level (or upper) ontology: a small, domain-neutral set of the most general categories — object, process, quality, role — that everything else inherits from. The international standard for one such foundation is the Basic Formal Ontology (BFO), standardized as ISO/IEC 21838-2, explicitly designed to support data exchange and integration across heterogeneous systems [7]. Building manufacturing ontologies on this common footing is the mission of the Industrial Ontologies Foundry (IOF), a community that articulated the semantic-interoperability problem for manufacturing and adopted shared principles for building reference ontologies that interoperate by design rather than by accident [3]. The IOF Core Ontology (the IOF Core) is a concrete, BFO-grounded mid-level model designed to harmonize heterogeneous manufacturing data — a path toward the single shared reference model that could turn the n² tangle into n mappings [4].

Why it matters

For data management, this chapter draws a hard line that is easy to miss. Every investment in the previous parts of this book — instruments, historians, integration standards, governance, integrity controls — can be flawless and still leave you unable to answer a simple cross-system question, because the data describes the same world in incompatible terms. Connectivity standards solved can the bytes arrive. Governance solved are the records trustworthy and owned. Neither solves do two numbers mean the same thing — and without that, every analytics project pays the wrangling tax again from scratch, and every combined dataset risks silently averaging Fahrenheit with Celsius. Semantics is not a finishing polish applied at the end; it is the layer that decides whether all the rest of your data can ever be used together.

The stakes are also regulatory. A batch record must be complete and traceable — in the United States, 21 CFR 211.192 requires that production and control records be reviewed and that any discrepancy be fully investigated — yet a record whose meaning is scattered across systems that disagree on names, units, and timestamps cannot easily be reconstructed end to end. Technology transfer compounds the risk: when a method moves between sites, ICH Q2(R2) on analytical procedure validation and ICH Q14 on analytical procedure development both assume that a specification stated at one site means the same thing at the next, units included. Semantic heterogeneity quietly undermines exactly that assumption.

In the real world

This is not theory. ISA-95 is the de facto reference model for business-to-plant integration, supplying the shared object definitions and terminology that interfaces between enterprise and manufacturing systems are built against [2], and the Allotrope Foundation's shared ontologies are an active, pharma-industry response to laboratory data that no two instruments described the same way [8]. The Industrial Ontologies Foundry is building the manufacturing reference ontologies, on a BFO foundation, to make this map-once-to-a-shared-model approach practical across vendors and companies [3][4]. And this is precisely the problem the U.S. NIIMBL institute's real-time lab-data proof of concept is designed to solve. That effort takes aim at the concrete heterogeneity this chapter catalogues: a sensor reporting TIC101.PV at one partner and temp_reactor at another reconciled to one agreed property; a Fahrenheit field and a Kelvin field resolved to a single Celsius quantity; an EQ-00457 asset tag and a BR-101 label recognized as the same vessel; and epoch, local, and UTC timestamps normalized to one instant — so that a question can be asked once and answered across organizational boundaries, the FAIR Interoperability principle made operational [1]. (NIIMBL's separate SABRE facility — a pilot-scale cGMP biomanufacturing and workforce-training center being built next door to scale up and de-risk advanced biomanufacturing — is a complement to this data work, not the data effort itself.)

Key terms

• Interoperability — the ability of separate systems to work together.
• Syntactic interoperability — agreement on data format: the message parses and the fields line up.
• Semantic interoperability — agreement on data meaning: both ends know two values describe the same kind of real-world thing.
• LCIM (Levels of Conceptual Interoperability Model) — a layered model naming interoperability from technical connection up through syntactic and semantic to pragmatic, dynamic, and conceptual levels.
• Semantic heterogeneity — the gap created when the same things are named and conceived differently across systems and people.
• Wrangling — the manual reconciliation of names, units, identifiers, and timestamps before data can be analyzed.
• Point-to-point mapping — a separate meaning-converter per pair of systems; suffers the n² problem.
• Reference data — the set of standard, approved values a field is allowed to take.
• Controlled vocabulary — a governed list of agreed terms with definitions.
• Ontology — a formal, machine-readable model of the concepts in a domain and the relationships among them.
• Top-level / upper ontology — a small, domain-neutral set of the most general categories that domain ontologies inherit from.
• BFO (Basic Formal Ontology, ISO/IEC 21838-2) — a standardized top-level ontology built to support data integration across heterogeneous systems.
• IOF (Industrial Ontologies Foundry) — a community building shared, BFO-grounded reference ontologies for manufacturing.
• IOF Core Ontology (IOF Core) — the IOF's BFO-grounded mid-level ontology that gives heterogeneous manufacturing systems one shared model to map to.

Where this leads

We have arrived at the word ontology by necessity: flat vocabularies fix names and units but cannot carry the relationships that meaning actually depends on. The next chapter, Ontologies and FAIR Data, builds that idea from the ground up — what a class and a relation are, how BFO and the IOF stack fit together, how Allotrope's AFO and the IOF Biopharma ontologies — governed by the BMIC (Biopharmaceutical Manufacturing Industry Council), a governance council defined in the next chapter — apply it to our field, and how the FAIR principles turn all of this from a philosophy of meaning into a working discipline of data management.