---
title: Industrial Data Ontology (IDO)
url: https://www.emergentmind.com/topics/industrial-data-ontology-ido
type: topic
---

# Industrial Data Ontology (IDO)

Industrial Data Ontology (IDO) denotes a family of ontology-based approaches for representing industrial data with a shared, computable vocabulary so that heterogeneous data can be integrated, queried, and reasoned over consistently. In the recent literature, the term is used in two closely related ways. First, it denotes a broader ecosystem of interoperable industrial ontologies and modules for assets, events, activities, documents, sensors, processes, and organizational structures. Second, it denotes the explicit top-level ontology “ISO DIS 23726-3: Industrial Data Ontology (IDO),” used as the apex of modular ontology stacks for engineering standards and semantic asset models [2404.05224][2510.01736].

## 1. Scope, terminology, and conceptual setting

IDO efforts aim to give industry a shared, computable vocabulary for assets, events, activities, and documents so that heterogeneous data can be integrated, queried and reasoned over in a consistent way. The immediate motivation is the fragmentation of industrial information across CMMS, ERP, sensor and historian systems, OEM manuals, FMEA/FMECA artefacts, work orders, process descriptions, and standards documents; these sources contain overlapping but inconsistent schemas, terminologies, and structures, which impedes cross-system analytics and trustworthy reuse [2404.05224].

The literature presents IDO as a modular rather than monolithic construct. In the IOF-aligned line of work, the broader “Industrial Data Ontology (IDO)” concept can be seen as the union, or ecosystem, of a domain-neutral core plus domain reference ontologies such as maintenance, supply chain, and future production modules. The same source also notes a separate “Industrial Data Ontology (IDO) community” emerging from the oil and gas sector, grounded in ISO 15926 and moving into ISO standardisation; in that setting, Iof-maint is being ported to an IDO/ISO‑15926–aligned variant [2404.05224].

A more explicit standardisation usage appears in machine-interpretable engineering standards for valve specification. There, IDO is “the top-level, ISO DIS 23726-3 Industrial Data Ontology (IDO)” at the apex of an industrial ontology design pyramid. The paper states that IDO is Part 3 of ISO 23726, that it will be an ISO standard, that it has been used previously as ISO/TR 15926‑14, and that it contains 49 classes, 92 object properties, and 2 data properties. Additional ontologies must adhere to its ontological commitments for reasoning to work [2510.01736].

This dual usage suggests that IDO is best understood as both an architectural principle and, in some settings, a specific upper ontology. The architectural principle is modular industrial semantics; the specific upper ontology is ISO DIS 23726-3 when a standards-aligned, top-level commitment is required.

## 2. Modular architecture and ontology stack design

A recurrent characteristic of IDO-oriented systems is modularity. Iof-maint is explicitly modular in two senses: it is a module within the IOF suite, importing IOF Core and thereby BFO, and it is also a reference ontology extracted from multiple application ontologies grounded in maintenance work orders, procedures, maintenance states, and failure modes and effects data. Its reference layer is intentionally minimal: 20 classes and 2 relations [2404.05224].

The same modular logic appears in industrial IoT and Industry 4.0 settings. ExtruOnt is divided into `components4ExtruOnt`, `OM4ExtruOnt`, `spatial4ExtruOnt`, `sensors4ExtruOnt`, and `3D4ExtruOnt`; only `components4ExtruOnt` is machine-type specific, while the other modules are designed to be reusable for other machines. The ontology extends and reuses SOSA/SSN, OM, and SIO, thereby positioning itself as a reusable semantic backbone for industrial big data rather than a one-off data model [2401.09789].

Model-based engineering work in aircraft assembly makes the same separation at the system level. The ontology sits in the middle of a three-layer architecture: a data layer of documents and information sources, an ontology layer aligned with BFO and IOF-Core, and a service layer comprising requirement management, architecture definition, verification with DES and 3D simulation, and visualization. In that architecture, the ontology is the semantic backend and “single point of truth” for multiple tools [2204.10636].

Large-scale deployment architectures also separate schema from storage. ArchiGraph keeps the TBox in an RDF triple store and distributes the ABox across relational and NoSQL engines, exposing a unified ontology-driven view with SPARQL and SHACL over a multi-model abstraction layer. This is an implementation pattern for an IDO at enterprise scale: ontologies define the conceptual schema, while large factual data remain in storage engines optimized for text, geospatial data, time series, or document structures [2103.05538].

A closely related modularization appears in Procedural Knowledge Ontology (PKO), which distinguishes `PKO core` from `PKO industry`. The core models procedures and executions generically, while the industrial module introduces machines, energy sources, padlocks, and PPE. This is not presented as a full IDO, but as a reusable procedural slice that complements a broader industrial ontology stack [2503.20634].

## 3. Formal semantics, upper-level alignment, and reasoning

The formal backbone of IDO-style ontologies is typically OWL 2 DL. Iof-maint is encoded in OWL 2 DL, supports OWL DL reasoning, and aligns with IOF Core, itself aligned with BFO 2020. The alignment establishes the distinction between continuants and occurrents and reuses upper-level relations such as `realizes`, `inheres in`, `precedes`, and `has participant`. Maintenance-specific classes are then defined against that background. For example, `FailureProcess` is exactly a `Process` that `realizes` some `DispositionToFail`, and `MaintenanceState` is exactly the union of `OperatingMaintenanceState`, `DegradedMaintenanceState`, and `FailedMaintenanceState` [2404.05224].

A different but equally explicit formalization appears in SemIoE. The ontology is defined as a bridge ontology over SSN/SOSA, BOT, and ORG:
$$
\mathcal{O}_{SemIoE} \equiv \mathcal{O}_{Bridge} \sqcup \mathcal{M}_{sosa/ssn} \sqcup \mathcal{M}_{bot} \sqcup \mathcal{M}_{org}
$$
Its bridge classes include `ioe:Agent`, `ioe:HAgent`, `ioe:SmartObject`, `ioe:System`, `ioe:Site`, `ioe:WorkflowElement`, `ioe:Process`, `ioe:Activity`, `ioe:Right`, `ioe:CurrentRole`, `ioe:Preference`, and `ioe:AgentRelation`. The paper states that the ontology includes 136 axioms, 20 classes and 10 object properties [2401.06667].

PKO formalizes another important distinction for industrial knowledge representation: the separation between plan and execution. `pko:Procedure` is modeled as a `pplan:Plan` and `dcat:Resource`, while `pko:ProcedureExecution` and `pko:StepExecution` are `prov:Activity`. PKO deliberately keeps logical axioms light and expects many integrity constraints to be enforced through SHACL shapes rather than through heavy OWL cardinalities and disjointness, a design choice explicitly motivated by flexibility and industrial-scale data handling [2503.20634].

In engineering design standards, formalization is driven by executable design rules. The valve-specification work encodes standard tables such as ASME B16.34 pressure–temperature ratings directly as OWL class expressions. Classes for material groups, valve parts, flange features, and environmental conditions are combined into equivalence axioms that allow a reasoner to infer whether a Valve Data Sheet or a manufacturer product type satisfies relevant standards. The approach uses HermiT for reasoning and OOPS! for ontology pitfall detection [2510.01736].

These patterns show that IDO work does not require a single formal style. BFO/IOF alignment, bridge ontologies over SSN/BOT/ORG, lightweight plan–execution ontologies, and standards-specific OWL class axioms all occur. The unifying feature is not one upper ontology alone, but the commitment to machine-interpretable semantics with reusable class/property systems and computable inference.

## 4. Data integration, knowledge graphs, and queryability

A central IDO objective is to provide a KG schema that supports integration and analytics over heterogeneous production data. Bosch welding studies make this objective explicit. In one case, a domain ontology created by welding experts contains 206 classes, 203 object properties, and 191 datatype properties, and all 176 data attributes are mapped to classes or properties. The problem identified is ontology–data mismatch: deep, sparse graph structures with blank nodes, cumbersome SPARQL paths, storage redundancy, and low usability for engineers [2209.11089].

Ontology reshaping is proposed as a remedy. The reshaped ontology better reflects the underlying data and removes blank nodes. In the Bosch evaluation, average query depth drops from approximately 4.2–4.4 to approximately 2.3–3.1, maximum depth falls from 5.0 to 3.0–4.0, KG generation becomes 7–8× faster, the number of entities is reduced to 1/2 to 1/6 of the baseline, storage space is reduced to about 2/3 of the baseline, and blank nodes are reduced to zero [2209.11089]. This suggests that an IDO used operationally as a KG schema must remain close to data structures and query workloads, rather than functioning only as a knowledge-oriented conceptual model.

Industry 4.0 work on ExtruOnt shows the same integration logic at sensor scale. The industrial scenario includes 51 sensors on one extruder, sampling at 1 Hz, producing approximately 1.6 billion records per year. Each raw record `[value, timestamp]` becomes an observation individual with `sosa:hasSimpleResult` and `sosa:resultTime`, linked to typed sensors and observable properties through reasoning. Sensor metadata include `indicatorId`, `sensorName`, `minValue`, `maxValue`, and OM units; the ontology also carries visualization recommendations using SIO chart types. The resulting semantic layer supports high-level visual queries, semantically driven UI generation, enriched data download, and cross-system analyses over sensors, machine components, and units [2401.09789].

At enterprise-storage scale, ArchiGraph demonstrates an implementation strategy for an IDO-backed knowledge graph without forcing all ABox data into a triple store. The system exposes SPARQL, REST, and GraphQL over PostgreSQL, MongoDB, HBase, and logical data mart adapters, while SHACL constraints and rules operate across the distributed ABox. On a dataset of 5,000,000 objects, text and date filtering queries are much faster than in a pure triple store: for example, a text filter query executes in 16.43 seconds in Fuseki versus 1.10 seconds through the ArchiGraph SPARQL endpoint; a date filter query executes in 7.56 seconds in Fuseki versus 0.74 seconds through the ArchiGraph SPARQL endpoint [2103.05538].

Together, these studies define the practical data plane of IDO: semantic annotation of operational data, workload-aware reshaping of ontology structures into query-friendly KG schemata, and multi-model runtime architectures that retain SPARQL and SHACL while exploiting industrial storage engines.

## 5. Representative industrial slices and domain modules

IDO appears in practice as a stack of domain modules and application ontologies rather than as a single all-encompassing artefact. The following examples illustrate the main slices already described in the literature.

| Module or example | Industrial slice | Notable characteristics |
|---|---|---|
| Iof-maint [2404.05224] | Maintenance and reliability | 20 classes, 2 relations, OWL DL, aligned with IOF Core |
| ExtruOnt [2401.09789] | Industry 4.0 machine, sensor, and visualization data | Modular ontology over SOSA/SSN, OM, SIO |
| Aircraft assembly ontology [2204.10636] | Product–process–resource–requirements integration | BFO and IOF-Core application ontology, tool-agnostic simulation |
| SemIoE [2401.06667] | IoE-based industry | Agents, systems, sites, roles, rights, preferences |
| PKO [2503.20634] | Procedures and executions | Core plus industry modules, PROV-O and P-Plan reuse |
| Valve standards stack [2510.01736] | Engineering standards and equipment selection | IDO-aligned modular ontologies for valves, piping, materials |

The maintenance slice is the most explicit example of a mature industrial reference ontology. Iof-maint covers failure effects, failure processes, functioning processes, undesirable dispositions, required functions, failure events, maintenance strategies, maintenance work order records, maintenance states, maintenance processes, maintenance activities, supporting maintenance activities, qualified maintenance persons, and qualification specifications. It was evolved by lifting recurring concepts from application ontologies validated on maintenance work orders, procedures, failure modes and effects analyses, and maintenance state data [2404.05224].

The process-design slice is illustrated by the Airbus assembly case. There, the ontology covers assembly processes, manufacturing operations, resources, materials, requirements, and MBSE structures represented through GOPPRRE. Manufacturing operations are vertices in a directed acyclic graph linked by `hasPredecessors`, with properties such as `op_duration`, `min_time`, `max_time`, `requiresResource`, and `requiresMaterial`. The ontology is then used to generate DES and 3D simulation inputs from the same semantic source [2204.10636].

The IoE and human-centric slice is captured by SemIoE. It models smart objects composed of systems, environment topology through sites and zones, organizations and roles, workflow elements, access rights at the environment, smart-object, and system levels, preferences, and inter-agent collaboration and delegation. This extends the reach of an IDO beyond sensors and assets toward policy, rights, and user-centric adaptation [2401.06667].

The procedural slice is addressed by PKO. Its design emerged from three industrial use cases: plant safety procedures such as LOTO, CNC commissioning processes, and mixed human–machine activities in grid management. PKO therefore models not only procedures, steps, versions, and resources, but also procedure executions, step executions, issues, errors, user questions, and user feedback occurrences. This fills a dimension that many industrial ontologies model only indirectly [2503.20634].

The standards and equipment-selection slice demonstrates a further extension. In the valve case, modular ontologies are built for valve-core, piping-core, materials-core, and standards such as API 6D, API 602, ASME B16.34, and ASTM material standards, all aligned to IDO. Functional location tags become OWL individuals that are instances of Valve Data Sheet specified valve classes, and reasoning establishes whether a specific VDS is compliant with relevant standards and whether a candidate product type satisfies the VDS [2510.01736].

## 6. Limitations, governance issues, and emerging directions

The literature consistently emphasizes that IDO modules are intentionally partial. Iof-maint is deliberately minimal and cannot by itself answer rich business questions; it must be combined with application ontologies, instance data, and sometimes SWRL rules. Coverage gaps remain around planning, scheduling, and generic business processes, and alignment between IOF/BFO-based ontologies and the emerging ISO/IDO, ISO 15926–based trajectory remains non-trivial [2404.05224].

Scalability and storage overhead are also recurring concerns. ExtruOnt demonstrates that semantic technologies add substantial storage cost: in the evaluated scenario, raw data occupy 44.88 GB, whereas RDF store or memory usage ranges from 171 to 793 GB. The authors nevertheless report acceptable response times for information and relation queries and treat the semantic overhead as justified by the gains in abstraction, visualization, and enriched analysis [2401.09789].

User- and workload-dependence is a further issue. Ontology reshaping is effective precisely because it bends a domain ontology toward actual tables, attributes, and analytics tasks, but that also means the operational KG schema may need re-reshaping as workloads change. The Bosch studies therefore imply a distinction between a rich central industrial ontology and compact, deployment-specific schemas derived from it [2209.11089].

Several ontologies remain intentionally lightweight. PKO does not model full BPMN-style control flow, advanced machine states, or rich uncertainty; SemIoE does not yet provide a full production or maintenance ontology and leaves explicit service modeling, stronger security and privacy semantics, and richer human interaction for future work [2503.20634][2401.06667]. The aircraft assembly ontology is demonstrated on real Airbus data, but reasoning performance at large industrial scale is not reported [2204.10636].

Two recent directions extend IDO beyond conventional KG integration. One concerns industrial standards. A standards-oriented KG framework introduces a hierarchical document ontology
$$
\mathcal{H} = \{\text{Section} \rightarrow \text{Subsection} \rightarrow \text{Subsubsection} \rightarrow (\text{Text} \cup \text{Table}) \rightarrow \text{Footnote}\}
$$
together with propositional rule structures for `has_condition_AND`, `has_condition_OR`, `has_consequence_AND`, and `has_consequence_OR`. In evaluation on ASTM and API documents, ontology-aware KG-RAG attains average F1 across datasets of approximately 0.454, compared with 0.277 for text-only RAG and 0.304 for conventional KG-RAG, and reaches F1 = 0.910, Accuracy = 0.913, and Recall = 0.926 on toxic clause detection [2512.08398].

The other direction concerns AI agent systems. A recent architecture treats the industrial ontology as a typed relational configuration validated at runtime through a three-operation contract—`resolve`, `contextualize`, and `annotate`—with invariants enforced by an AIOps orchestration layer. In a controlled experiment across six industry configurations and 72 tool invocations using Qwen3-32B, unconstrained tool parameters produce a 43% hallucination rate for domain identifiers, whereas ontology-grounded parameters reduce this to 0% [2605.11234]. This suggests that IDO is moving from a passive integration schema toward an active runtime contract for digital twins, analytics tools, and multi-agent systems.

Across these lines of work, the common trajectory is clear. IDO is becoming a semantic substrate for industrial integration, analytics, design validation, procedural support, standards digitalization, and AI governance. The principal open problem is no longer whether industrial ontologies can be built, but how to govern modular evolution, preserve interoperability across standards ecosystems, and keep runtime representations simultaneously formal, scalable, and operationally usable.

Source: https://www.emergentmind.com/topics/industrial-data-ontology-ido