Patterns

Pattern Library¶

The ontology-based interoperability (OBI) ecosystem, which extends the Industrial Data Ontology (IDO) through reusable, domain-neutral modeling patterns, is realized as a coherent family of complementary pattern documents. Each pattern defines a specific modeling concern that recurs in industrial data, engineering design, and lifecycle information management. The Guidelines to model Property Knowledge based on the Principles defined in ISO 23726-1 including the alignment to the Industrial Data Ontology (IDO) (Version 0.2) provide the conceptual foundation for these patterns — particularly in Chapters 3 (Guidelines to model property knowledge) and 4 (Application principles). The patterns listed below translate those conceptual guidelines into implementable, ontology-based modeling rules that can be reused across tools, domains, and organizations.

IDO as upper ontology offers different possibilities to model the same case (one example are the different levels of expressiveness described in the Property Classes Pattern). To achieve interoperability, modeling principles and patterns should be defined.

Modeling patterns for ontologies that are intended to be interoperable are important for several key reasons:

Consistency Across Ontologies: Interoperable ontologies often need to work together or integrate seamlessly. Modeling patterns provide standardized ways to represent concepts and relationships, reducing ambiguity and ensuring that similar concepts are modeled similarly across different ontologies.
Improved Reusability: When modeling patterns are followed, ontology components become more modular and reusable. This means that elements of one ontology can be more easily reused in another, reducing duplication of effort and promoting knowledge sharing.
Enhanced Interoperability: Interoperability is the ability of different systems and organizations to work together. Standard modeling patterns ensure that ontologies can communicate effectively, enabling data integration, sharing, and semantic alignment across diverse domains.
Facilitated Maintenance and Evolution: Consistent modeling makes it easier to update and maintain ontologies over time. Changes in one part of an ontology are less likely to cause unintended effects elsewhere when standard patterns are used.
Better Tool Support: Ontologies designed using standard modeling patterns can be more easily supported by automated tools for reasoning, validation, and querying. This improves their usability and functionality in practical applications.
Reduced Learning Time: For developers and users of ontologies, familiar modeling patterns reduce the time and effort needed to understand and work with new ontologies. This supports broader adoption and collaboration.

Some of the cases for patterns for IDO aligned ontologies which should be discussed, reworked where needed, agreed, and released for use in the industry community are:

Property modeling (details see the Property Classes Pattern)
as class (highest level of expressiveness)
as object property (shortcut with middle level of expressiveness)
as datatype property (shortcut with lowest level of expressiveness)
IDO does not allow to assign properties (lis:Quality) directly to all of the classes defined in IDO. Therefore, patterns are needed for the different cases to express something with properties. Here some examples:
Maximum temperature which should be achieved in a heating process at the time series data (e.g., of the current temperature of the water at the water out port of a boiler)
Data quality rules for the property assignment to a class (independent from the level of expressiveness)
Is the property mandatory or optional — maybe dependent on the lifecycle status of the class it is assigned to?
Is it allowed or needed to have more than one value? (E.g., Can a Person have more than one given name?)
Definition of the expected datatype of the value of an instance of a property (details see the Data Type and Value Representation Pattern in this document set).
A property can have different characteristics that should only be used in certain contexts. For example, the property Voltage can be used as Nominal Voltage in the context of the specification or operation and as Rated Voltage in the context of a product. These two properties can have a rule like "Rated Voltage should be higher than Nominal Voltage" to select products which fulfill the specification (or operational requirements). Unit and quantity kind modeling (unit without quantity kind is incomplete, e.g., the unit Volt is used for the quantity kind Voltage and Electrical Potential).
Modeling of lists of values
Use of lists of values in different contexts like properties and classes (including inheritance hierarchy — which means that the valid values are reduced more because the classes are becoming increasingly specific.)
How to model the assignment of different classifications to the same resource?
Modeling of partonomies including restrictions on the cardinality (e.g., Power transformers and Reactors have windings, therefore they should inherit this from a parent class, but the Power transformer must have exactly two or more windings and the Reactor must have exactly 1 winding).
Synonyms
Identification keys
Polymorphism as defined in IEC 61360-1.
Modeling of dependent cardinalities (e.g., the property serial number becomes mandatory at the latest when the nameplate of a product is to be produced).

Property Classes Pattern¶

The name of the pattern defined in this document is: Property Classes Pattern

Motivation and Purpose¶

This pattern defines the upper-level classes of properties and explains how each is to be modeled, governed, and applied. It introduces and distinguishes the following Property Types: Quality Property, Identifying Property, Classification Property, Reference Property, Descriptive/Textual Property. Each Property has a Bearer — the entity to which the property applies — and each Property Type has distinct semantic intent, governance expectation, and validation mechanism.

This pattern formalizes the conceptual differentiation of properties, where identification, classification, descriptive, and contextual roles of properties are discussed. It also defines the boundary between ontology-level Relations and instance-level Reference Properties. Finally, it provides the conceptual basis for Competency Questions that guide Subject-Matter Experts (SMEs) during knowledge capture.

The pattern outputs: (1) a controlled vocabulary of Property Types; (2) rules for selecting the correct Property Type for a given information need; (3) clear attachment of each Property to its Bearer; and (4) a foundation for tool-supported SME elicitation and data governance alignment.

Motivation¶

In complex knowledge and data environments, the concept of a “property” has evolved into a highly overloaded term. Within engineering models, ontologies, and metadata systems, the same syntactic construct — a property — is used to express a broad variety of meanings: physical measurements, identifiers, classifications, descriptive text, or contextual references to responsible entities.

This lack of semantic differentiation leads to ambiguity, redundancy, and misalignment between systems. A weight value, a project manager, and a document category may all be implemented as “properties,” yet their conceptual nature and governance requirements are entirely different. Such inconsistencies result in fragmented metadata structures, hinder interoperability, and complicate automated reasoning and data validation.

A formal typology of property classes is therefore required to provide:

semantic clarity — each property expresses a clearly defined type of characteristic;
modeling discipline — modelers can select the correct class of property for each information need;
governance integration — each property type can be associated with the appropriate authority, validation rule, and controlled value domain;
interoperability and re-use — consistent property semantics across ontologies, data sources, and lifecycle phases.

The conceptual foundation for this typology was first outlined in Handbook > Property typology. That chapter introduced the initial categorization of property types: Quality Property, Identifying Property, Classification Property, Reference Property and Descriptive/Textual Property, and established the need for a consistent, ontology-based framework to manage them.

The present Property Classes Pattern builds directly upon that conceptual groundwork by transforming the descriptive guidance of the Guidelines into a formal, implementable modeling pattern within the framework of the Industrial Data Ontology and the ISO 23726 series. Within this broader context, the Industrial Data Ontology (IDO) serves as a stable upper ontology that defines the high-level conceptual framework for ontology-based interoperability across industrial domains. While the IDO provides foundational constructs such as lis:Quality for Quality Properties, it does not yet prescribe how non-Quality Property types should be modeled.

The Property Classes Pattern therefore extends the IDO concept system by introducing explicit modeling constructs for these other types of properties, ensuring semantic consistency across qualitative, representational (includes identifying, classification and descriptive/textual), and referential domains. The Property Classes Pattern thus responds to a fundamental modeling challenge: to separate the types of meaning that are currently conflated under the generic notion of “property” and to make these distinctions explicit in ontology design.

Theoretical and normative foundation¶

The typology defined in this pattern is not arbitrary; it emerges from the intersection of several internationally standardized conceptual frameworks:

Semantic Representation (ISO 704:2022, W3C OWL 2 2012): These standards distinguish between attributes (qualities of an object), relations (links between objects), and identifiers (unique designations of individual objects). The Property Classes Pattern extends this triad by introducing a systematic, class-based differentiation within the attribute space itself.
Data and Reference Governance (ISO 8000-115:2018, ISO 8000-100:2019): These define how identifiers and reference data must be created, registered, and maintained to ensure persistence, uniqueness, and traceability. Representational and Reference Properties, as defined in this pattern, are the modeling constructs that realize these governance principles in semantic form.
Metadata and Register Management (ISO/IEC 11179-3:2023, ISO 19135-1:2015): These standards describe how value domains, permissible values, and register items are governed under authority. In this pattern, those concepts materialise as Controlled Sets of Entities — the authoritative sources from which property values are drawn.
Measurement and Quantities (ISO 80000-1:2024): This provides the quantitative foundation for Quality Properties, ensuring that measurable attributes remain distinct from representational or referential ones.

The synthesis of these conceptual and normative frameworks results in a dual-dimensional foundation for property modeling:

a conceptual (ontological) dimension, defining the type of characteristic a property represents within a concept system (per ISO 704:2022 and ISO 23726-3:2025); and
a governance (data) dimension, defining how the property’s values or targets are controlled, registered, and maintained (per ISO/IEC 11179-3:2023 and ISO 19135-1:2015).

Within ontology-based information systems, these two dimensions correspond to two complementary levels of authority:

Ontology-level governance, which maintains the conceptual and relational structure of the ontology under institutional authority (for example, the IDO Maintenance Agency or the W3C Industrial Ontologies Community), ensuring terminological consistency and semantic coherence; and
Data-level governance, which manages the registration, validation, and persistence of permissible values within controlled sets and reference data registers, ensuring traceability and authoritative control of data instances.

Building on the foundations, the Industrial Data Ontology (IDO) provides the conceptual layer of authority under ontology-level governance. Domain ontologies and operational data models apply these concepts at the data level, where governed values and assignments are maintained under data-level governance. This pattern operates precisely at the interface between these two governance levels, translating the conceptual principles of the IDO and the modeling guidance from the “Guidelines to model Property Knowledge …” into formal, verifiable constructs.

Together, these mechanisms form a continuous governance framework that spans from conceptual definition to operational data management, ensuring that every property class defined in the Industrial Data Ontology is both semantically coherent and institutionally controlled.

Building upon this dual framework, the next section establishes the practical modeling boundary between ontology-level relations and data-level reference properties. Whereas Theoretical and normative foundation defines the underlying conceptual and governance criteria, Distinction between Relations and Reference Properties applies these criteria to the modeling decision itself — determining in which situations a link between entities should be expressed as an ontology-level ObjectProperty (Relation) or as a reified class of Reference Property. This decision boundary is fundamental for semantic precision, maintainability, and interoperability across Industrial Data Ontology implementations.

Distinction between Relations and Reference Properties¶

Building on the dual-dimensional framework introduced in Theoretical and normative foundation, this section defines the modeling boundary between the two principal constructs that connect entities within an ontology. From this dual foundation emerge two distinct types of modeling constructs that serve complementary purposes within ontology-based information systems:

Relations, which realize the conceptual dimension by expressing intrinsic, context-independent dependencies between classes, and
Reference Properties, which realize the governance dimension by expressing governed, context-specific assignments between instances.

Both constructs establish links between entities, but they operate under different governance regimes and correspond to different levels of authority as defined in Theoretical and normative foundation:

Relations are maintained under ontology-level governance, ensuring conceptual integrity and semantic coherence within the controlled concept system;
Reference Properties are maintained under data-level governance, ensuring authoritative control and traceability of governed instance data.

Distinguishing between these constructs is fundamental for determining how semantic links are to be represented in a model:

whether as an ontology-level ObjectProperty that belongs to the conceptual structure of the ontology,
or as a reified Reference Property class that captures governed contextual information at the data level.

This conceptual boundary provides the theoretical foundation for all subsequent modeling and governance rules developed in this pattern. The following chapters build on this distinction to demonstrate how these constructs are applied in practice, how they interact with controlled sets of entities, and how they contribute to a coherent integration of ontology-level semantics and data-level governance.

Industrial and Practical Motivation¶

The previous sections (Theoretical and normative foundation and Distinction between Relations and Reference Properties) motivate the Property Classes Pattern from a conceptual and governance point of view: they explain why a property typology is required, how it is grounded in international standards, and how it distinguishes between Relations and Reference Properties as two different modeling constructs. The practical motivation for this pattern is more direct and comes from observed gaps in current modeling practice. In many industrial ontologies and data models, quantitative characteristics are treated with much higher formal discipline than non-quantitative ones.

For example, the class lis:Quality provides a rigorous modeling construct for measurable characteristics such as pressure, voltage, or temperature. Such quantitative properties are typically associated with physical units, permitted value ranges, validity conditions, and other constraints that can be checked automatically. However, industrial information management requires equally disciplined structures for non-quantitative characteristics, including:

identifying and designating information (identifiers, project codes, country codes, document IDs);
classificatory information (category, status, lifecycle phase);
descriptive textual information (human-readable descriptions, labels);
governed contextual assignments (responsible organization, approving authority, country of installation).

In practice, these aspects are often modeled ad hoc: as free-text literals, as untyped “attributes”, or — critically — as poorly specified object properties that are used as if they were Relations, even when they actually represent governed contextual assignments. This undermines governance, weakens validation, and makes alignment with the IDO as an upper ontology difficult to sustain across domains.

The Property Classes Pattern addresses this gap by generalising the idea of a dedicated property class beyond quantitative measurement. It introduces formal classes for non-quantitative property types — such as Representational Properties (for identifiers and designations) and Reference Properties (for governed contextual assignments that point to controlled sets of entities) — and defines their governance expectations. This means:

Non-quantitative information is no longer modeled as “just a string” or “just a link”, but as an explicit, typed property class with declared governance.
Responsibilities, approvals, locations of installation, and similar contextual assignments are modeled as Reference Properties, not as Relations. Their permissible values must come from an authorised and controlled set (for example: a register of organizations, an approved list of roles, the ISO 3166-1:2020 country set).
Identifiers, textual designations, and codes are modeled as Representational Properties that capture how a thing is named, labeled, or classified for human or system use, without confusing that representational layer with physical qualities.

In doing so, the Property Classes Pattern provides the missing structural counterpart to lis:Quality. It enables downstream ontologies and industrial data sets to express all relevant property types — quantitative, representational, referential — in a way that is both:

semantically compatible with the IDO under ontology-level governance, and
operationally governable under data-level governance.

This is essential for lifecycle interoperability, auditability, regulatory traceability, and controlled data exchange between organizations, systems, and engineering disciplines. The differentiation of Property Classes outlined in this pattern addresses a long-standing gap within ontology-based industrial information management.

Building on this motivation, the following section defines the purpose of the Property Classes Pattern within the IDO framework, explaining how it operationalises the conceptual and governance dimensions defined above within the broader OBI ecosystem.

Purpose¶

The Property Classes Pattern defines how different kinds of properties are to be represented within the conceptual framework of the Industrial Data Ontology (IDO). Its primary purpose is to operationalise the conceptual and governance dimensions introduced in Theoretical and normative foundation by translating them into a concrete, ontologically consistent typology of Property Classes.

Operating entirely within the ontology-level governance of the OBI ecosystem, this pattern provides the formal mechanism by which new Property Classes can be introduced, aligned, and maintained as integral parts of the ontology. It ensures that every Property Class — whether quantitative, representational, or referential — remains both semantically coherent within the conceptual framework and institutionally governed through established data governance principles. Each Property Class defined in this pattern — Quality, Representational, Reference, and Controlled-Set — materialises one or more aspects of these two governing dimensions. These four pattern-level classes correspond to the five conceptual Property Types introduced in Handbook > Property typology: Identifying, Classification, and Descriptive/Textual Properties are modeled as subtypes of the Representational class, while Quality and Reference map directly to their respective classes. Controlled-Set is not a user-facing Property Type but the governing construct that defines the authoritative value domains from which property values are drawn. They are modeled as IDO-level constructs that provide a clear separation between:

ontology-level relations, which are maintained as part of the conceptual structure of the IDO; and
governed property classes, which manage the contextual or referential characteristics of instances under data-level authority.

Within the broader OBI ecosystem, these Property Classes function as ontology-level building blocks that support both conceptual and data governance continuity across subsequent layers:

Domain Ontologies specialise the IDO for specific engineering or business domains by applying these Property Classes in domain-specific contexts;
IDO Extensions (also referred to as IDO-aligned ontology modules) expand the IDO itself, introducing new, but pattern-consistent, conceptual structures such as controlled sets of entities or master-data property schemes.

Through this integration, the Property Classes Pattern provides the governed interface between the conceptual and governance dimensions of the IDO. It formalizes the relationship between ontology-level design and data-level implementation, ensuring that all property constructs are traceable to their conceptual origin and governed by recognised authority in accordance with the ISO 23726 series and the Guidelines to model Property Knowledge based on the Principles defined in ISO 23726-1.

By realizing this alignment, the pattern consolidates the semantic integrity of the OBI ecosystem and enables its controlled evolution toward comprehensive coverage of both measurable and non-measurable characteristics, thus establishing a stable basis for future patterns addressing controlled value sets, reference data, and master-data governance.

Competency Questions¶

The Pattern defines how property-related knowledge is to be captured, structured, and governed within the Ontology-Based Interoperability (OBI) ecosystem, which builds upon the Industrial Data Ontology (IDO) as its stable upper ontology. Its intent is to provide a consistent, pattern-based mechanism through which domain expertise can be transformed into ontology-compliant data representations without requiring direct modeling knowledge from the subject-matter experts (SMEs).

This mediation is realized through Competency Questions (CQs) and pattern-governed tooling that jointly ensure semantic correctness and governance compliance.

Pattern-based collaboration model¶

The pattern formalizes a three-layer collaboration model between:

Subject-Matter Experts (SMEs) — who provide factual and contextual knowledge about entities and their properties in their own language;
Ontology Engineers — who design and maintain the reusable patterns, classes, and governance logic within the OBI ecosystem; and
Tools implementing the Patterns — which guide the SMEs through predefined question sets (Competency Questions) and automatically translate their answers into ontology-compliant structures.

In this model, ontology engineers no longer create individual data structures manually. Instead, they act as designers and stewards of the patterns, ensuring that each pattern correctly implements the ontological principles defined in the OBI ecosystem and aligns with external governance sources (such as ISO standards, reference data registers, or controlled vocabularies). Their role shifts from modelling to governance: they define the rules, not the instances.

Competency Questions as a methodological bridge¶

The Competency Questions (CQs) are the core mechanism that enables this transformation of knowledge. They represent the methodological bridge between the domain expert’s language and the ontology’s formal representation. Each CQ corresponds to a decision point in the modeling process and is linked to a specific part of the Pattern. When implemented in a tool, the CQs appear as structured, context-aware dialogues that ask the expert precisely the questions needed to capture all relevant semantics. By answering the CQs, the SME effectively “models” the knowledge — but without interacting directly with the ontology. The tool interprets each answer, determines which type of Property applies (Quality, Identifying, Classification, Reference, or Descriptive/Textual), and generates the corresponding ontology statements, including all necessary links to controlled sets of entities, identifiers, or quantities.

Resulting governance alignment¶

Through this process, every piece of property knowledge captured from experts becomes:

semantically classified, through the explicit selection of the applicable Property type,
governed, through the automatic linkage to controlled reference data or quantity definitions, and
interoperable, because it conforms to the shared semantics of the OBI ecosystem.

The Pattern (e.g. Property Classes Pattern) thus operationalises the principles defined in the Guidelines to model Property Knowledge based on the Principles defined in ISO 23726-1, extending them into a formal, pattern-driven methodology for ontology-based interoperability.

Examples applies this general method specifically to the Property Classes Pattern by introducing typical modeling situations — drawn from industrial contexts — that illustrate how each Property type emerges and how the corresponding Competency Questions are derived.

Contexts of use¶

Thematic context¶

The patterns defined in this pattern document are specifying the classes data type part of the whole value specification of a property. IDO offers only general restrictions regarding the data type. Figure 1 defines the data type as rdfs:Literal which is very generic.

classes data type as rdfs literal — Figure 1: The classes data type defined as rdfs:Literal

The patterns defined in this pattern document provide more specific data types as extension of the IDO.

Note

The thematic context could be more than only for lis:datumValue because the patterns could be relevant for values of properties having a parent class other than lis:Quality.

Figure 2 and Figure 3 show the two identified other patterns. They both follow the overall pattern of lis:Quality. At first the pattern for the non-qualifying properties called Representational Properties:

classes data type representational properties — Figure 2: Pattern for the non-qualifying properties called Representational Properties

And now the second the pattern for Reference Properties (details see Distinction between Relations and Reference Properties):

classes data type reference properties — Figure 3: Pattern for the Reference Properties

Ontology context¶

The patterns in this pattern document are mainly defined for Knowledge Ontologies. In addition rules are defined how to generate shortcuts to be used in Integration Ontologies out of the patterns defined for Knowledge Ontologies.

Levels of expressiveness¶

IDO offers an abstract and philosophical foundation where the main elements of the language are predefined in a general manner. How to use the elements defined in IDO is described more on a general level and leaves room for interpretation. This means that different IDO-based ontologies are not automatically interoperable. This can be illustrated with Figure 4. It explains the two shortcuts lis:qualityQuantifiedValue and lis:hasQualityQuantifiedAs based on lis:hasQuality, lis:Quality, lis:qualityQuantifiedAs, lis:QualityDatum and lis:UnitOfMeasure. Please refer to the legend at Figure 5.

motor mass representations — Figure 4: Representations of mass of a motor. Source: ISO/DIS 23726-3:2024 Industrial Data Ontology — DIS stage

representations legend — Figure 5: Legend for the representations

The prefix lis: is used as abbreviation of the IDO namespace, and it stands for "lifecycle information system"; This prefix was defined before the name Industrial Data Ontology (IDO) was defined. The picture shows three patterns with different levels of expressiveness. Here expressiveness means to define knowledge as explicitly as possible. The pattern with the highest expressiveness is shown in the following extract from Figure 6.

motor mass high expressiveness — Figure 6: Representations of mass of a motor — focus on the elements of the whole picture

The pattern with less expressiveness is shown in the following extract of Figure 7.

motor mass shortcut qualified as — Figure 7: Representation of mass of a motor with focus on the lis:hasQualityQuantifiedAs short-cut

The pattern with the lowest expressiveness is shown in the next extract of Figure 8.

motor mass shortcut quantity value — Figure 8: Representation of mass of a motor with focus on the lis:qualityQuantityValue short-cut

All three patterns are valid because they support different use cases:

The pattern with the highest expressiveness supports the use case to collect all the knowledge about a property (lis:Quality) in the most explicit manner to enable detailed querying for the different aspects of a property (e.g., like it is defined in IEC 61360-1 as well).
The pattern with the lowest expressiveness supports the use case to map data to IDO-based modeling directly (ex:Motor and ex:mass_kg could be columns in a database table and ex:Motor71 and 20 a dataset in this database table).
The third pattern is something between the other two. This pattern is for example used for the RDF serialization of ECLASS (see "Technical Specification 110 — ECLASS Serialization as RDF — Part 1", chapter 6.6 "Property") or is used in QUDT (qudt:Quantity is a combination of lis:Quality and lis:QualityDatum; see Figure 9; more details about this are described later).

qudt main elements — Figure 9: Main elements defined in QUDT (Source: https://www.qudt.org/)

Figure 10 shows different levels of expressiveness. These levels are not yet defined. One principle could be to annotate IDO-based ontologies by a level of expressiveness. The highest level of expressiveness offers all information to automatically create the lower levels of expressiveness. This should be expressed as well, perhaps with a new AnnotationProperty "is derived from" like shown in the following picture.

motor mass derived from — Figure 10: Representation of mass of a motor, extended with the 'is derived from' relation

Table 1 offers a summary of the different aspects of expressivity.

Table 1: Summary of the levels of expressivity
Aspect	Available	To be discussed and introduced
Language	Basic elements for three levels of expressivity	Levels of expressivity are not yet defined Modeling elements which define how lower levels of expressivity can be derived automatically from the higher level
Knowledge/Data Governance Policies	Use cases for each level	Guidelines which describe the levels of expressivity including the criteria which are relevant to identify the level of expressivity of an ontology Modeling patterns for the different levels of expressivity Rules on how to derive the lower levels of expressivity from the higher levels
Knowledge-Driven Data Integration Systems	—	Tools which implement the guidelines, modeling patterns and rules by collecting the relevant information from the user and creating the triples automatically in line with the guidelines based on the input of the user. Vision: AI could support extracting the knowledge from data and creating already a first draft of the different levels of expressivity.

The comparative analysis of IDO elements against IEC 61360-1:2017 — including the element mapping and standards integration framework — is in Handbook > Alignment with IEC 61360-1:2017.

Structure and Elements¶

Overview¶

Elements¶

The following picture shows all elements from IDO together with elements defined in the Domain Ontology (prefix ex:) and Instance Data (also prefix ex:, which should be discussed). The different parts of this picture are described step by step.

ido physical object to uom example — Figure 11: Model extraction of the elements from lis:PhysicalObject to lis:UnitOfMeasure including an example of how to use

Two Alternatives to Model Properties Based on IDO¶

Figure 11 shows the following differences in addition to the fact that all elements are shown:

the elements defined in the domain ontology are shown explicitly,
lis:Quality is replaced by lis:hasPhysicalQuantity and
lis:QualityDatum is replaced by lis:ScalarQuantityDatum.

IDO allows both modeling options. Although the same thing should be expressed, the two models are different in their precision and thus in their interoperability. This example alone shows that modeling rules are required to ensure that models can be interpreted consistently. Table 2 summarizes the findings of this section.

Table 2: Knowledge governance and data integration aspects for IDO Properties
Aspect	Available	To be discussed and introduced
Language	—	—
Knowledge/Data Governance Policies	Possibilities to model Properties based on IDO	Guidelines that define rules as to when which of the possible modeling patterns defined in IDO should be used.
Knowledge-Driven Data Integration Systems	—	Infrastructure to guide the users to select the suitable pattern in line with the guideline for creating and maintaining Properties based on IDO.

In the following, some suggestions for rules are worked out by going through the above picture from left to right in individual parts.

Patterns in a knowledge ontology¶

Relation between `lis:Object` and `lis:Quality` and Their Subclasses¶

The following picture focusses on the relation between lis:Object and lis:Quality and its subclasses (left part of Figure 11). The green area legend domain ontology green shows what a Domain Ontology could look like:

The Class ex:Motor is defined
The Property ex:Mass is defined
An owl:Restriction on the relation between the Class ex:Motor and the Property ex:Mass is defined (an alternative could have been a SHACL shape)

The corresponding instances (data represented in a knowledge graph) are shown in the yellow area legend instance data yellow .

ido object quality focus — Figure 12: Focus on the elements lis:PhysicalObject and lis:Quality in IDO including an example of how to use them

The owl:Restriction is assigned to the Class ex:Motor and could be used to define the expected cardinality of the assigned Property ex:Mass. The cardinality defined in the W3C standards OWL and SHACL can have a minimal value and a maximal value.

the minimal value expresses if a Property is optional (value 0) or mandatory (value 1) in the context of a Class and
the maximal value expresses if a Property can be used only once (value 1) or multiple times (no maximum value is defined). Example for the necessity of multiple values could be the Property "First name" or the Property "Rated frequency" (some power transformers are built for rated frequency 50 Hz and 60 Hz).

The minimal value may depend on the lifecycle of the Class. For example, the Property "Serial number" of the motor is at the beginning of the lifecycle not available and could not be mandatory. However, it must be mandatory at the latest by the time the motor nameplate is to be produced. Such a dependency could be added to the restriction (Table 3).

Table 3: Relation between lis:Object and lis:Quality and their subclasses
Aspect	Available	To be discussed and introduced
Language	—	—
Knowledge/ Data Governance Policies	Possibilities to model cardinality for the relations between a Class and its Properties based on W3C standards Cases that could be expressed with cardinality of the relations between a Class and its Properties	Guidelines that define patterns for at least the above-mentioned cases. The patterns should be available as `owl:Restriction` and as SHACL shape If possible then conversion rules from `owl:Restriction` to SHACL shape and vice versa should be defined
Knowledge- Driven Data Integration Systems	—	Infrastructure to support the users to define the cardinality of the relations between a Class and its Properties, to create the defined `owl:Restrictions` or SHACL shapes in the background and a corresponding converter from OWL to SHACL and vice versa.

Relation between `lis:Quality` and `lis:QualityDatum` and Their Subclasses¶

The next part is the relation between lis:Quality and lis:QualityDatum and its subclasses, shown in Figure 13. The green area legend domain ontology green shows how this part of a Domain Ontology could look like:

The Property ex:Mass is repeated from the first part
An owl:Restriction on the relation between the Property ex:Mass and lis:ScalarQuantityDatum is defined (an alternative could have been a SHACL shape)

The corresponding instances (data represented in a knowledge graph) are shown in the yellow area legend instance data yellow . In addition, we see that IDO already has defined an owl:Restriction for the (inverse) relation between lis:ScalarQuantityDatum and lis:PhysicalQuantity. No cardinality is defined in this restriction.

ido quality datum focus — Figure 13: Focus on the elements lis:PhysicalQuality and lis:QualityDatum in IDO including a usage example

The missing owl:Restriction is assigned to the Property ex:Mass and could be used to define the expected cardinality of the assigned lis:ScalarQuantityDatum. The cardinality defined in the OWL and SHACL W3C standards can have a minimal value and a maximal value.

The minimal value should always be 1, because an instance of a Property ex:Mass makes only sense if it has an instance of lis:ScalarQuantityDatum.
The maximal value can be used to express whether lis:ScalarQuantityDatum can have no historical values (value 1) or historical values (no maximum value is defined). An example for the necessity of history is the Property "Name" assigned to an organizational unit, because it may be interesting how the name of the same organizational unit changed over time.

The findings are summarized in Table 4.

Table 4: Relation between lis:Quality and lis:QualityDatum and their subclasses
Aspect	Available	To be discussed and introduced
Language	—	—
Knowledge/ Data Governance Policies	Possibilities to model cardinality for the relations between a Property and its `lis:QuantityDatum` or `lis:ScalarQuantityDatum` based on W3C standards Cases that could be expressed with cardinality of the relations between a Property and its `lis:QuantityDatum` or `lis:ScalarQuantityDatum`	Guidelines that define patterns for at least the above-mentioned case. The patterns should be available as `owl:Restriction` and as SHACL shape If possible then conversion rules from `owl:Restriction` to SHACL shape and vice versa should be defined
Knowledge- Driven Data Integration Systems	—	Infrastructure to support the users to define the cardinality of the relations between a Property and its `lis:QuantityDatum` or `lis:ScalarQuantityDatum`, to create the defined `owl:Restrictions` or SHACL shapes in the background and a corresponding converter from OWL to SHACL and vice versa.

Relation between `lis:QualityDatum` and `lis:UnitOfMeasure` and Their Subclasses¶

The last part is the relation between lis:QualityDatum (including its subclasses) and lis:UnitOfMeasure. Figure 14 shows no area for the Domain Ontology. This part is missing in the picture, although restrictions — like defining the allowed units depending on the selected physical quantity or the data type of the literal — could be relevant here. These points are taken up again later in IEC 61360-1.

For now, we are focusing on the restrictions defined in IDO which are the following:

an owl:Restriction on the relation between lis:ScalarQuantityDatum and lis:UnitOfMeasure is defined, and
an owl:Restriction on the relation between lis:ScalarQuantityDatum and the datatype rdfs:Literal is defined.

An alternative could have been a SHACL shape. These two restrictions show which kind of restrictions could be defined at Domain Ontology level. The restrictions defined in IDO deliberately leave details open. This is different in standards like IEC 61360-1:2017 or QUDT. It therefore makes sense to take a closer look at these standards before delving deeper into the direction defined by IDO.

ido datum uom focus — Figure 14: Focus on the elements lis:QualityDatum and lis:UnitOfMeasure in IDO including a usage example

Description of the Pattern Generation Algorithm¶

From Knowledge Ontology to Integration Ontology¶

From Integration Ontology to Knowledge Ontology¶

Description of the Pattern Validation Algorithm¶

Pattern validation algorithm for knowledge ontologies¶

Pattern validation algorithm for integration ontologies¶

Examples¶

Examples for knowledge ontologies¶

Centrifugal Pump Tag¶

Several drafts for patterns are mentioned in the document. How CFIHOS, STEP and DEXPI could communicate on ontology level is shown in this section by generalizing the model shown in "CFIHOS Semantics to IDO" and combining it with the Process Plant part from "DEXPI to IDO". This is a first starting point for discussing the needed modeling patterns. In the next step this example should be completed and the modeling patterns used should be documented for reuse.

The following principles/patterns are part of the example:

Separation between general ontologies and specific views on the general ontologies
Inheritance hierarchy: Hierarchy from a general level down to a specific level (Note that it is not a classification hierarchy; a picture of an inheritance hierarchy used at Siemens Energy is shown in Figure 18.)
Different patterns to model properties
Synonyms
ClassIdentifiers

The example shows three different possibilities to model the same case. Figure 15 shows the model where patterns for high expressivity are used; Figure 16 shows patterns with lower expressivity; and Figure 17 shows patterns with even lower expressivity.

An example of an inheritance hierarchy developed at Siemens Energy is illustrated in Figure 18.

patterns high expressivity — Figure 15: Model with patterns for high expressivity

patterns medium expressivity — Figure 16: Model with patterns for medium expressivity

patterns lower expressivity — Figure 17: Model with patterns for lower expressivity

inheritance hierarchy siemens — Figure 18: An example of an inheritance hierarchy developed at Siemens Energy

Examples for integration ontologies¶

Links to other patterns¶