A practical guide to giving manufacturing data shared meaning and relationships so people, applications and AI agents can interpret operational information consistently across systems, sites and domains.
A Semantic Data Layer is the part of the industrial data architecture that defines what operational entities mean, how they relate to one another, and what rules apply to those relationships. It typically combines a shared semantic model, a machine-readable ontology, and a knowledge graph populated with the real entities that exist in the operation.
Manufacturing systems can exchange data without sharing the same understanding of what that data means. A historian may know a tag. MES may know a work order. ERP may know a material number. A maintenance system may know an asset record. The Semantic Data Layer establishes the shared concepts and relationships that connect those representations into a coherent model of the operation.
Its purpose is not simply to put labels on data. It provides an explicit representation of operational meaning: what a reactor is, which site it belongs to, which process it participates in, which material it is processing, which work order is active, what capability it provides, and which events have affected its state.
What does this operational entity mean, and how is it related to everything else?
This becomes especially important as information moves beyond the application that created it. Humans can often infer context from naming conventions, experience and tribal knowledge. Software and AI need those assumptions to be made explicit.
Industrial integration traditionally focuses on moving data between systems. That solves access, but not necessarily interpretation. The same concept can have different names in different systems, while the same word can mean different things depending on the domain.
A work center, production line, location, equipment group, or simply a label in one application?
A tag path may imply the answer to a human without defining a stable machine-readable identity.
An order may be released for production while a material lot may be released by quality. The word alone is ambiguous.
An event is more useful when it can be connected to the batch, recipe, work order, material and equipment involved.
These ambiguities are manageable while people remain in the loop and systems are integrated one project at a time. They become a serious limitation when information needs to be reused across sites, joined across domains, queried flexibly or made available to AI agents.
The terms are often used interchangeably, but it is useful to separate their roles. Think of them as three connected parts of the Semantic Data Layer.
Defines the concepts, vocabulary, meanings and relationships used to describe the manufacturing domain.
Formalizes those concepts, properties, relationships and constraints in a representation software can interpret.
Uses the ontology to represent the real sites, equipment, processes, materials, events and relationships that actually exist.
Before a machine can reason over the operation, the organization needs a consistent vocabulary for describing it. This is the semantic model: a conceptual specification of the important entities, their definitions and the relationships between them.
Standards such as ISA-95 are useful because they already provide established terminology for many manufacturing operations concepts. Reusing accepted terminology where it fits reduces unnecessary ambiguity. A semantic model can then extend that common foundation with terminology specific to the organization's products, equipment, processes and domains.
A semantic model should be precise enough to constrain interpretation without trying to encode every possible concept in manufacturing into one universal model.
The semantic model describes what concepts mean. The ontology expresses those concepts, relationships and rules in a representation software can inspect and query.
The ontology describes the possible structure of operational reality. It can state that a mixer is a type of equipment, that a process can require a capability, or that an event may change the state of an entity. It does not yet say which specific mixer exists in Munich or which batch was processed yesterday.
Ontologies can be represented using RDF/OWL, JSON-LD, schemas, property graphs or other machine-readable approaches. The technology is important, but the model is more important than the serialization.
A knowledge graph is created when the abstract model is populated with the real entities, classifications and relationships that exist in the operation.
Now applications can traverse operational context instead of relying on rigid table joins or application-specific identifiers. A query can start with a real asset, follow its class definition, discover its parent work center, identify the process running there, find related events, and connect those events to historical measurements stored elsewhere.
A useful core ontology should capture the concepts that recur across production, maintenance, quality, inventory and other operational domains without becoming an enormous universal taxonomy.
These concepts provide enough structure to describe work, physical things, operational records, people or software agents, where things occur, what resources can do, how entities participate, what happened and what condition resulted.
Process AFFECTS PhysicalEntity
Entity PARTICIPATES_IN Process
Entity PLAYS_ROLE Role
Entity HAS_CAPABILITY Capability
Process REQUIRES_CAPABILITY Capability
Process IS_GUIDED_BY OperationalEntity
Process OCCURS_AT Location
Event OCCURS_DURING Process
Event CHANGES_STATE Entity
Entity HAS_STATE State
Process HAS_SUBPROCESS Process
Location CONTAINS LocationThe core should remain stable and deliberately abstract. Production, maintenance, quality and logistics can then extend it with the vocabulary they require while preserving semantic compatibility across the wider manufacturing model.
This layered approach avoids two extremes: one monolithic ontology that becomes impossible to govern, and many disconnected domain models that cannot be combined.
The semantic layer becomes useful when the same real-world entity can be recognized across different systems. Stable identifiers provide that bridge.
equipmentId: EQ-MUC-HG401
workCenterId: WC-MUC-200-L1
siteId: SITE-MUC
batchRecordId: B-4711
workOrderId: WO-123The Unified Namespace may publish a measurement for EQ-MUC-HG401. The operational datastore may preserve its historical pressure. MES may associate it with WO-123. The knowledge graph can use the same identity to connect those records to the equipment class, work center, process, capabilities and related entities.
Semantic integration does not require copying every data point into the graph. Shared identities allow the graph to describe relationships while high-volume time-series and transactional data remain in systems designed to store them.
The Semantic Data Layer complements the operational layers beneath it. DataOps prepares information. The Unified Namespace exposes current operational state and events. The operational datastore preserves history. The semantic layer connects identities, definitions and relationships across those sources.
This separation is important. A semantic layer does not need to become your message broker, historian, lakehouse or transactional database. It provides the connective meaning that lets those systems be interpreted together.
The Unified Namespace is excellent for knowing where information is and what is happening now. A hierarchical namespace can provide substantial context, for example the enterprise, site, area and work center associated with a message, but it should not be expected to encode every semantic relationship in the organization.
A UNS event such as BatchStarted can carry stable identifiers for the batch, equipment, work center, product and work order. The graph can then use those identities to resolve deeper relationships that do not belong in the MQTT topic or payload: equipment class inheritance, process dependencies, material genealogy, capabilities, organizational ownership or cross-domain links.
Knowledge graphs are powerful for traversing relationships, but they are not automatically the best place to store every high-frequency measurement or years of process history. Time-series databases, historians and operational datastores remain better suited to those workloads.
The graph can determine which entities, relationships and time windows are relevant. The historical platform can then retrieve the underlying time-series or event records. This keeps each technology aligned with the workload it handles best.
A knowledge graph cannot repair inconsistent source identities by itself. If the same piece of equipment appears as MX04, Mixer_4 and Asset-88271 across systems with no mapping between them, semantic integration begins with identity resolution.
DataOps is therefore a practical upstream dependency of the semantic layer. It helps ensure that the entities entering the shared architecture can be mapped consistently into the ontology and knowledge graph.
Large language models are probabilistic. They are very good at interpreting natural language, but they should not be expected to invent the structure and rules of a manufacturing operation from disconnected database records every time they receive a task.
A Semantic Data Layer provides an explicit model of operational reality that agents can query before deciding what information to retrieve or which actions are permissible.
The graph may tell the agent that the reactor is part of a particular production line, that a premix unit feeds it, that Batch B-4711 is active, that the process is guided by Recipe R-22 and that a quality hold applies to the material lot. Those relationships provide a structured investigation path rather than leaving the model to guess which data is relevant.
The semantic layer acts as operational grounding: it helps agents discover entities, understand relationships, constrain interpretation and decide which live, historical or transactional systems they need to query next.
Traverse equipment, process, material, recipe, event and state relationships before querying the relevant historical evidence.
Find information across production, maintenance, quality and inventory without requiring one giant relational schema.
Find equipment by class, capability, location or relationship rather than only by a known asset identifier.
Give agents a governed map of operational concepts, relationships and allowable reasoning paths.
Represent assets together with processes, materials, events and dependencies rather than limiting a twin to one application's object model.
Map different source-system models into common semantic concepts without forcing every underlying system to use the same schema.
There are several valid ways to implement semantic models and ontologies. The right choice depends on the reasoning, query, interoperability, governance and operational requirements of the use case.
Industry40.tv's implementation examples use Neo4j because a graph-native model allows ontology definitions and operational instances to coexist in the same environment and be traversed with the same query language. That is an architectural choice, not a requirement of the Semantic Data Layer itself.
Once applications and AI depend on a semantic model, changes to that model become architecture changes. Concepts, relationships and identifiers therefore need clear ownership, versioning and review.
Core concepts, relationship semantics, URI or ID conventions, naming rules, version policy and shared domain interfaces.
Domain teams can add production, maintenance or quality concepts without redefining the shared core or creating conflicting meanings.
Useful governance questions include: Who can add a new ontology class? When is a new subclass justified? How are deprecated concepts handled? Which source identifiers map to the same entity? What happens when a domain model changes? How are graph instances validated against the intended ontology?
Technology can store relationships, but it cannot decide which concepts and relationships are meaningful for the business.
An ontology becomes difficult to understand and govern when every source-system field is promoted into the core model.
A classification hierarchy is useful, but an ontology also models meaningful relationships, constraints and behavior across concepts.
Use the graph for entities and relationships; let historians and time-series stores handle the high-volume data they are designed for.
Semantic relationships are unreliable if different systems cannot agree on which real-world entity a record refers to.
A hierarchical topic path is useful context, but deeper cross-domain relationships belong in a richer semantic representation.
Production, quality and maintenance models should extend shared concepts rather than creating incompatible semantic islands.
LLMs can interpret language, but explicit operational definitions and relationships provide more reliable guardrails for industrial reasoning.
The important architectural principle is that semantics connect the data estate rather than replacing it. Live values remain available through the UNS. History remains in the operational datastore or historian. Systems of record retain their transactions. The semantic layer provides a common map for understanding how the information in those systems relates.
The best semantic initiatives begin with questions the organization cannot answer reliably today, then model only enough of the domain to answer them.
For example: contextual root-cause analysis, equipment discovery, AI-agent grounding or production genealogy.
Identify the concepts the use case requires and reuse established manufacturing terminology where it fits.
Specify how processes, equipment, materials, locations, events, states and operational records connect.
Formalize the shared concepts in a machine-readable representation without modelling the entire enterprise.
Introduce production, maintenance, quality or other concepts required by the first use case.
Map source-system identifiers to the real-world entities represented in the semantic layer.
Create instances for a limited operational scope, one site, area, line or process, and connect them to the ontology.
Use shared IDs to relate UNS events and datastore records to graph entities rather than duplicating every measurement.
Provide applications and AI agents with controlled graph queries, semantic search or APIs appropriate to their role.
Extend the graph and ontology as additional use cases demonstrate the need for new concepts and relationships.
Use this page as the architectural overview. The resources below go deeper into ontology design, graph implementation, domain modelling and the relationship between semantics, the UNS and industrial AI.
The leading IIoT & AI educational platform for digital manufacturing teams