Skip to content

Guidelines

Guidelines for the Arrowhead fPVN Handbook on industrial semantics – Using IDO as upper ontology

This document is an entry-level guide to the Arrowhead fPVN Handbook on Industrial Semantics. It explains why semantic technology is needed in industrial data management, how IDO (ISO 23726-3) organizes industrial knowledge, and how the pattern library and use cases connect the framework to real data model standards (Figure 1). Readers who want full depth should proceed to the Handbook; this document helps orient them and provides a quick-start reference.

IDO standards-based ontology ecosystem
Figure 1: A standards-based ontology ecosystem for interoperability and meaningful data. IDO (ISO 23726-3) forms the upper ontology core; surrounding layers carry domain-specific ontologies, external group artefacts, and enterprise data. Source: DNV / ISO/TC 184/SC 4, April 2026.

Document suite

This framework is delivered as four companion artifacts, as shown in Table 1:

Table 1: Document suite: four companion artifacts and their intended audiences.
Document Purpose Audience

Guidelines
(this document)

Entry-level navigation and overview of the framework. The recommended starting point.

New readers; management; project evaluators

Handbook

Full rationale, methodology, ontology architecture, and pattern library overview.

Ontology engineers; standards contributors

Pattern Library

Normative, per-pattern specifications with reusable OWL and SHACL structures.

Implementers; tool developers

Use Cases

Worked examples: DEXPI pump lifecycle, power transformer, CFIHOS Semantics.

All; especially first-time adopters

IDO top-level categories
Figure 2: IDO top-level categories: lis:Object (independent entities that persist through time), lis:Dependent (inherent qualities or potentials of an object), and lis:Temporal (entities relating to or occurring in time). Source: DNV / ISO/TC 184/SC 4, April 2026.

The three top-level classes in Figure 2 (lis:Object, lis:Dependent, lis:Temporal) partition the industrial world into independent physical and functional entities, the properties and qualities that inhere in them, and the activities and events that occur over time. Every class in every domain ontology aligned to IDO is placed under one of these three top-level classes.

Reasons for a W3C Ontology

The Arrowhead fPVN initiative proposes a fundamentally different approach based on World Wide Web Consortium (W3C) standards and semantic technologies. Despite the availability of information model standards in industry since the mid-1990s and the strong promises from standardization organizations, seamless interoperability has not been achieved. This gap is mainly due to several structural challenges:

  • Different vocabularies are used across standards, even within the same standard family;

  • Diverging model architectures and different modeling languages have been applied;

  • Standardization groups have often prioritized the success of their own standards over broader business needs;

  • Newly developed standards often duplicate existing concepts, but in different ways.

The choice between a standard database and semantic technology is not just about storage; it is about how quickly a structure can adapt to change. While Relational Database Management Systems (RDBMS) are ideal for fixed schemas, they often create bottlenecks. In engineering projects, a user-requested schema extension can take a year. With an RDF triple store and an ontology, that same extension takes a fraction of that time. It turns data management into something as fluid as editing a spreadsheet.

Here is how this approach solves the complexity we face:

  • For EPC contractors: Data Integration at Scale: In an engineering project, we often manage 40 or more databases and hundreds of spreadsheets. EPC contractors can have hundreds of very different projects. Merging the data of one project into a single store is only feasible via RDF because the data is so versatile. The ontology carries the meaning, relationship definitions and source mappings, that only an engineer understands, allowing them to perform their own mappings instantly.

  • For Owner/Operators: Harvesting Unstructured Data: Most owner/operator data reside in PDFs, drawings, and 3D models. We can use Large Language Models (LLMs) to harvest this data into an RDF ontology. Software for that has been developed in the past year. Because the owner/operator builds the ontology and provides meaning, the AI can infer the meaning of the data, rather than just performing keyword searches.

  • For Suppliers: Futureproofing: We are moving toward Digital Product Passports and Asset Administration Shells with over 100,000 distinct properties and thousands of product models. A traditional relational schema cannot scale to those relationships. RDF is the natural receiver for these massive key-value pairs, using AI to map data based on the ontology’s definitions.

Interoperability through alignment
Figure 3: Interoperability through alignment: point-to-point integration (left) requires n×n mappings. With IDO as a shared upper ontology (right), each system aligns once. Source: DNV / ISO/TC 184/SC 4, April 2026.

Choice for W3C

RDF represents data as subject–predicate–object triples identified by URIs, giving every resource a globally unique, dereferenceable identity. Formal semantics — expressed through OWL ontologies — enable inference and reasoning over the data. Standards bodies such as ISO/IEC and industrial consortia such as CFIHOS and DEXPI publish domain ontologies in RDF/OWL precisely to achieve shared, machine-interpretable vocabularies across systems.

Property graphs such as Neo4j model data as nodes, relationships, and properties. Traversal queries are fast and the schema is flexible, which suits use cases such as supply chain analysis or asset hierarchy navigation. However, property graphs have no built-in semantics and no pathway to ontology alignment.

For projects requiring inferential reasoning and standards-based interoperability, RDF/OWL is the appropriate choice. For high-performance traversal over locally scoped, well-understood data, property graphs may be preferable.

For a list of RDF triple stores, see https://www.w3.org/wiki/SparqlImplementations

Combining domain Ontologies

Instead of forcing everything into one giant model, this approach uses multiple knowledge graphs, each representing a different standard or domain. By linking these graphs through IDO, it delivers value faster and avoids the complexity and cost of large-scale mapping projects (Figure 3). The more connections are added, the more intelligent the system becomes. The setup handles three types of data:

  • Fixed, such as standards and reference models

  • Changing, such as design data

  • Real-time, such as live operational data

These types of data coexist in a flexible and scalable system, making it easy to share and evolve information across different stages (Table 2).

Table 2: Domain standards covered in this framework and their alignment status.
Standard Coverage in this framework Status
DEXPI P\&ID functional objects, tag properties, pump lifecycle Covered
CFIHOS v2.0 Plant object hierarchy, property list, data handover Covered
ISO 10303 (STEP) Product data exchange, AP 242 / AP 239, property structures Covered
IMF (ISO/IEC 81346) Aspect classification, functional/physical/locational breakdown Covered
ISO 15926-4 Reference data library vocabulary, PCA RDL Partial
AFO (Arrowhead Framework Ontology) Microservice-layer runtime bridge In progress

For the full treatment of each alignment, see Handbook > Standards alignment.

Downloading IDO and domain ontologies

The way to use multiple domain ontologies together is to let all of them align to IDO as the upper ontology. The resources listed below are the starting points for implementation:

The Handbook also documents the alignment approach for each of these standards.

Property modeling workflow

The IDO property description pattern applies across all domain ontologies. The workflow for modeling a new property for a plant object is:

  1. Identify the bearer — the plant object that carries the property (e.g., cfihos:CentrifugalPumpT, dexpipla:Pump).

  2. Choose the property type — a lis:Quality (measurable quantity), a lis:Designation (identifier/label), or an object property (relationship to another resource).

  3. Attach the datum — a lis:QualityDatum carrying the numeric or string value, the unit of measure (QUDT), and optionally a lifecycle stage qualifier.

  4. Apply the relevant IDO pattern — choose from the Pattern Library (e.g., Quantity Kind and Measurement, Descriptive and Annotation, Classification and Controlled Sets).

  5. Validate with SHACL — use the pattern’s accompanying SHACL shape to check that the instance graph is structurally correct before loading into the knowledge graph.

For the full pattern specifications, see Pattern Library. For the full methodology rationale, see Handbook > Property aspects and Unified property reification model.

Worked example: CFIHOS Semantics

This section gives a compact introduction to the IDO implementation method through the CFIHOS domain. A full worked example — including five detailed modeling scenarios (quantifiable property, property aspect, material, tag name, manufacturer), OWL restrictions, and lifecycle-tagged values — is documented in Use Cases > CFIHOS Semantics.

The solution of implementing IDO will be explained in incremental steps, starting with the CFIHOS RDL spreadsheets, then the diagramming method, then moving to RDF.

Diagramming method

Take the Centrifugal Pump class (Figure 4), on an RDL spreadsheet. The centrifugal pump has CFIHOS ID CFIHOS-30000521 and is subclass of pump. This RDL class can be TAG lifecycle or EQUIPMENT lifecycle both.

CFIHOS RDL Tag Class spreadsheet excerpt
Figure 4: CFIHOS RDL Tag Class spreadsheet (extract): centrifugal pump (CFIHOS-30000521) highlighted as a dynamic pump, subclass of pump.

The data dictionary (Table 3) shows that the generic permissible properties for TAG entity is tag name. EQUIPMENT has the tag name too, but its unique key is equipment code (Table 4). Tag name in EQUIPMENT is a reference to TAG, which we will solve by using the isImplementedBy relationship. Which is the example we will use, since the name of a plant item (tag name) is the most used property in process plant data.

Table 3: CFIHOS TAG entity: permissible properties and their obligation level.
TAG An object designed for performing functional requirements and serving as a specification for equipment
Plant code The plant where the tag is or will be located Identifier
Tag name The full name of a tag Identifier
Tag description A functional description of the tag Mandatory
Parent tag name An identification of the parentage of the tag Optional
Process unit code The process unit within the plant to which the tag provides part of the functionality Mandatory
Area code The geographical area within the plant where the tag is located Optional

TAG Entity Example

  • Class: centrifugal pump

  • Tag Name: 11P-101

  • Lifecycle Stage: TAG

Table 4: CFIHOS EQUIPMENT entity: permissible properties and their obligation level.
EQUIPMENT A physical device designed to perform a function
Equipment code A code used to identify uniquely the equipment. Identifier
Plant code The plant where the equipment is or will be installed Optional
Tag name The full name of a tag Optional
Equipment class name The full name of the tag or equipment class Mandatory
Manufacturer company name A name used to uniquely identify the company. who manufactures the equipment Optional
Model part name A unique name to identify the model part of the manufacturer, and that the equipment is associated with Optional
Equipment manufacturer serial number A unique identification number for the equipment as prescribed by the manufacturer Optional

EQUIPMENT Entity Example

  • Class: centrifugal pump

  • Equipment no: 7345393

  • isFulFilledBy: object for 11P-101 → object for 7345393

  • Lifecycle Stage: EQUIPMENT

The tag name 11P-101 and the isImplementedBy are the key identifiers used across disciplines and systems to refer to the same functional item, even though the context and permissible properties differ.

OWL class block diagram notation
Figure 5: Diagram notation: OWL class block. C = class; the block records the URI, rdf:type owl:Class, and rdfs:label.

The diagramming method is explained in Figure 5. Consider this diagram block. The C means it is a class. There are 2 triples shown.

  • cfihos:CFIHOS-3000521T is the URI for the class.

  • It is declared (a means the predicate rdf:type) as an owl:Class.

  • It has a human-readable label centrifugal pump using predicate rdfs:label.

In RDF (shown as Turtle) these 2 triples are: (explain RDF? link)

@prefix cfihos: <https://data.cfihos.org/rdl> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

cfihos:CFIHOS-3000521T a owl:Class ;
    rdfs:label "centrifugal pump" .

Next example:

OWL class hierarchy and individual diagram notation
Figure 6: Diagram notation: OWL class hierarchy and individual. Open triangle = rdfs:subClassOf; plain arrow = rdf:type; I = named individual.

Figure 6 illustrates an individual (denoted by I for individual). It is a plant item, such as a pump symbol on a Piping and Instrumentation Diagram (P&ID) or a real cooling water pump operating in a facility. The ex: prefix is used to indicate a placeholder namespace (short for "example.com"). In practice, this could be replaced with the actual namespace used in a project database containing millions of plant items. The four-digit number (e.g., 2384) symbolizes part of a UUID. (explain UUID: link). For example, if the project code is L9GC and the company domain name is example.com, then ex:2384 could correspond to a full identifier like this: https://data.example.com/l9gc/2384a1b2-3c4d-5e6f-8a9b-c0d1e2f3a4b5

The arrow with the open triangle means rdfs:subClassOf. RDF of this diagram is:

@prefix cfihos: <http://data.cfihos.org/rdl/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex: <https://data.example.com/l9gc/> .

cfihos:CFIHOS-3000550T a owl:Class ;
    rdfs:label "pump" .

cfihos:CFIHOS-3000521T a owl:Class ;
    rdfs:label "centrifugal pump" ;
    rdfs:subClassOf cfihos:CFIHOS-3000550T .

ex:2384 a owl:NamedIndividual ;
    a cfihos:CFIHOS-3000521T .

Intrinsic and assigned properties

The IDO class lis:Dependent is defined as: "An entity that is an inherent quality or realizable potential of an object." The key word is inherent: a material of construction is an inherent quality of a plant object, but a "required at site date" is not — it is an assigned property, attached by a project context rather than inherent to the object.

In the current Handbook framework, both intrinsic qualities (lis:Quality) and assigned designations (lis:Designation) are modeled as subclasses of lis:Dependent, with the distinction captured through class choice and pattern selection rather than a formal property hierarchy. The Pattern Library provides separate patterns for each case. For the full rationale, see Handbook > Intrinsic and assigned properties.

The IDO hierarchy

The properties with namespace lis: are IDO, with cfihos: is CFIHOS Semantics. For IDO refer to the Turtle file downloadable from https://rds.posccaesar.org/services/downloads/, or specifically https://rds.posccaesar.org/ontology/lis14/ont/core/1.0/. To see the definitions refer to the online upper ontology https://rds.posccaesar.org/ontology/lis14/ont/core/

  • lis:Object

  • lis:FunctionalObject

    • lis:System

  • lis:InformationObject

  • lis:UnitOfMeasure

    • lis:Scale

  • lis:Location

    • lis:Site

    • lis:SpatialLocation

    • lis:LineInSpace

    • lis:PlaneInSpace

    • lis:PointInSpace

    • lis:VolumeInSpace

  • lis:Organization

  • lis:PhysicalObject

    • lis:PhysicalArtefact

    • cfihos:TagClass

      • cfihos:CFIHOS-30000097T infrastructure

      • cfihos:CFIHOS-30000098T instrument equipment

      • cfihos:CFIHOS-30000101T IT and telecom equipment

      • etc.

    • cfihos:EquipmentClass

      • cfihos:CFIHOS-30000097E infrastructure

      • cfihos:CFIHOS-30000098E instrument equipment

      • cfihos:CFIHOS-30000101E IT and telecom equipment

      • etc.

    • lis:MateriallyClassifiedObject

    • lis:Feature

    • lis:InanimatePhysicalObject

    • lis:Stream

    • lis:Organism

    • lis:Person

  • lis:Phase

  • lis:Dependent

  • cfihos:Property

    • cfihos:CFIHOS-10000166 tag name

    • cfihos:CFIHOS-40000001 actual length

    • cfihos:CFIHOS-40000002 actuator motion

    • cfihos:CFIHOS-40000003 actuator seal material

    • cfihos:CFIHOS-40000004 adjustment ring material specification

    • cfihos:CFIHOS-40000005 air cooler type

    • cfihos:CFIHOS-40000006 air preheater type

  • lis:Potential

    • lis:Disposition

    • lis:Capability

    • lis:Function

  • lis:Interest

  • lis:Role

  • lis:Quality

    • lis:MaterialCompositionQuality

    • lis:PhaseQuality

    • lis:PhysicalQuantity

    • lis:ShapeQuality

  • lis:Temporal

  • lis:Activity

    • lis:ActivityProfile

  • lis:Event

  • lis:SpatiotemporalRegion

  • lis:TemporalRegion

    • lis:InstantRegion

    • lis:Instant

    • lis:IntervalRegion

    • lis:Interval

  • lis:Actual

  • lis:Specified

Top Class to Ontology

The top classes are cfihos:TagClass and cfihos:EquipmentClass. Transformation to triples:

@prefix cfihos: <https://data.cfihos.org/rdl> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix lis: <http://rds.posccaesar.org/ontology/lis14/rdl/> .

cfihos:TagClass a owl:Class ;
    rdfs:label "Tag Class" ;
    rdfs:subClassOf lis:PhysicalArtefact .

cfihos:EquipmentClass a owl:Class ;
    rdfs:label "Equipment Class" ;
    rdfs:subClassOf lis:PhysicalArtefact .

RDL Class to Ontology Class

The RDL classes are in the CFIHOS RDL under tabs Tag Class and Equipment Class. To show the transformation, take 1 example:

CFIHOS RDL centrifugal pump entry
Figure 7: CFIHOS RDL Tag Class tab: centrifugal pump entry (CFIHOS-30000521) with class definition.

CFIHOS RDL pump parent class entry
Figure 8: CFIHOS RDL Tag Class tab: pump entry (CFIHOS-30000550), the parent class of centrifugal pump.

Transformation to triples:

@prefix cfihos: <https://data.cfihos.org/rdl> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

cfihos:CFIHOS-3000521T a owl:Class ;
    rdfs:label "centrifugal pump" ;
    rdfs:subClassOf cfihos:CFIHOS-30000550T .

RDL Tag Class Property to Ontology OWL restriction

The RDL relationships of classes to properties are for Tag Class: Tag Class Property tab. The example is a power cable having a length.

CFIHOS RDL power cable property list
Figure 9: CFIHOS RDL Tag Class Property tab: property list for power cable (CFIHOS-30000360), including length (CFIHOS-40000201). 

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix lis: <http://rds.posccaesar.org/ontology/lis14/rdl/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix cfihos: <http://data.cfihos.org/rdl/> .
@prefix ex: <http://example.com/> .

cfihos:CFIHOS-30000360T a owl:Class ;
    rdfs:label "power cable" .

cfihos:CFIHOS-40000201 a owl:Class ;
    rdfs:label "length" .

cfihos:RealMeasureTypeDatum a owl:Class ;
    rdfs:label "RealMeasureTypeDatum" .

unit:Meter a owl:Class ;
    rdfs:label "Meter" .

lis:hasQuality a owl:ObjectProperty .

lis:QualityQuantifiedAs a owl:ObjectProperty .

ex:6343 a owl:NamedIndividual ;
    a cfihos:CFIHOS-30000360T ;
    lis:hasQuality ex:7345.

ex:7345 a owl:NamedIndividual ;
    a cfihos:CFIHOS-40000201 ;
    lis:QualityQuantifiedAs ex:6343 .

ex:5566 a owl:NamedIndividual ;
    lis:datumValue "1000"^^xsd:string ;
    lis:datumUOM unit:Meter .

OWL property instance pattern for power cable length
Figure 10: OWL property instance pattern: power cable ex:6343 → lis:hasQuality → quality ex:7345 → lis:qualityQuantifiedAs → datum with value 1000 and unit Meter.

OWL restrictions for properties: allowable properties for tag and equipment classes.

@prefix : <http://example.org/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix lis: <http://rds.posccaesar.org/ontology/lis14/rdl/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix cfihos: <http://data.cfihos.org/rdl/> .
@prefix ex: <http://example.com/> .

cfihos:CFIHOS-30000360T a owl:Class ;
    rdfs:label "power cable" .

cfihos:CFIHOS-40000201 a owl:Class ;
    rdfs:label "length" .

cfihos:RealMeasureTypeDatum a owl:Class ;
    rdfs:label "RealMeasureTypeDatum" ;
    rdfs:subClassOf lis:QualityDatum .

lis:QualityDatum a owl:Class ;
    rdfs:label "QualityDatum" .

lis:hasQuality a owl:ObjectProperty .

lis:QualityQuantifiedAs a owl:ObjectProperty .

cfihos:CFIHOS-30000360T rdfs:subClassOf cfihos:CFIHOS-xxxx1 .
cfihos:CFIHOS-xxxx1 a owl:Restriction ;
    owl:onProperty lis:hasQuality ;
    owl:allValuesFrom cfihos:CFIHOS-40000201 .

cfihos:CFIHOS-40000201 rdfs:subClassOf cfihos:CFIHOS-xxxx2 .
cfihos:CFIHOS-xxxx2 a owl:Restriction ;
    owl:onProperty lis:QualityQuantifiedAs ;
    owl:allValuesFrom cfihos:RealMeasureTypeDatum .

OWL class restrictions for power cable length
Figure 11: OWL class restrictions: owl:allValuesFrom restricts lis:hasQuality to length for power cable, and lis:qualityQuantifiedAs to RealMeasureTypeDatum.

QualityDatum taxonomy

The QualityDatum taxonomy is used for all the data types which can be applied. For example, in the previous chapter, the property length was an allowable property for power cable, and its QualityDatum was RealMeasureTypeDatum. This QualityDatum type defines the data type for length as having a value (a Real) and a unit of measure (a QUDT unit ID). The term Measure indicates value + unit of measure.

The complete list of QualityDatum is:

BinaryTypeDatum
BooleanTypeDatum
ClassReferenceTypeDatum
DateTimeTypeDatum
DateTypeDatum
IntMeasureTypeDatum
IntTypeDatum
NonTranslatableStringTypeDatum
NumberTypeDatum
RationalMeasureTypeDatum
RationalTypeDatum
RealMeasureTypeDatum
RealTypeDatum
StringTypeDatum
TimeTypeDatum
TranslatableStringTypeDatum

Lookup lists

Lookup lists are a special part in the Ontology that has classes (the names of the lists) and each class has an enumerated list of items

Example: Lookup list name: API pump type

Table 5: API pump type lookup list.
API Type Family Mounting / Orientation Key Design Feature
OH1 Overhung Horizontal foot-mounted End-suction flexible coupling
OH2 Overhung Horizontal centerline-mounted Better alignment high tempera-ture
OH5 Overhung Close-coupled Motor directly attached
OH5 BS 4082-1 Overhung Close-coupled British standard variant
OH6 Overhung Vertical inline Compact inline piping
BB1 Between Bearings Horizontal Axially split casing
BB2 Between Bearings Horizontal Radially split casing
BB3 Between Bearings Horizontal multi-stage Radially split multi-stage
VS1 Vertical Suspended Vertical Diffuser casing
VS2 Vertical Suspended Vertical Volute casing
VS3 Vertical Suspended Vertical Inline design
VS4 Vertical Suspended Vertical Line shaft sump pump
VS5 Vertical Suspended Vertical Cantilever no submerged bear-ings
VS6 Vertical Suspended Vertical Double casing inline
VS7 Vertical Suspended Vertical Vertical turbine

This is one of the most elaborate examples. In many domain ontologies (e.g. ISO 15926-4) these are just specialized classes from Centrifugal Pump. However, it is like this in CFIHOS. So, provision must be made to be able to use these kinds of lookups.

Contributing and reviewing partners

Representing partner Contributor Contents Review
AITIA Péter Olaszi X X
Fluor/CFIHOS Onno Paap X
TBHK Torbjörn Holm X