iiRDS in the semantic network

by parson on November 28, 2022

Corresponding services: Metadata models and Smart content and iiRDS

What are the benefits of top-level ontologies and intelligent data exchange for iiRDS?

What happens when data and metadata from different systems are exchanged? What is the role of ontologies in data exchange? How can top-level ontologies improve exchanges? And how does the intelligent information standard iiRDS relate to these upper ontologies? In this post, we look at the issue of uncertainty when exchanging data packages, the potential of top-level ontologies for eliminating ambiguity and unlocking valuable resources, and present some international initiatives that take advantage of these benefits.

Foto: Diego Delso, delso.photo, License CC-BY-SA (Wikimedia Commons)

Background: problems with exchanging data using iiRDS as an example

iiRDS is an exchange format for technical documentation that standardizes the exchange of content and metadata on this content and facilitates the delivery of documentation as intelligent information. As an exchange format, iiRDS has two components. The first is a package format for delivery. The second is a standardized metadata vocabulary for technical communication in the form of an ontology. This ensures that the metadata of different documentations speak the same language.

But despite a common language, misunderstandings may occur when an iiRDS package is exchanged between two parties. Exchanging iiRDS packages and metadata between two systems is similar to an exchange between two different worlds as each has its own context. A product variant in one person’s product world may be used as a component by the recipient and sorted accordingly in the metadata model.

iiRDS’ extensibility is a strength, because it allows parties to integrate custom metadata as new classes or instances into the iiRDS vocabulary. However, extensions place certain demands on producers and processors of iiRDS packages, because it must be prevented that the parties interpret metadata in different ways. Such misinterpretations may be the source of errors when iiRDS packages are exchanged between different systems. 

An example: The package with iiRDS metadata of a ball bearing (Bearing) is transferred from the producer to the receiver. In this process, the SuperBearing product variant is incorrectly packaged as a component and then integrated as a machine part at the receiving end. The product variant does not have a weight, but the machine part does. In this way, the weightless product variant becomes a real component.

The iiRDS metadata of a ball bearing is transferred from the producer to the receiver and incorrectly packaged in the process.

But is the reinterpretation of this type of metadata actually important? If it is simply a matter of exchanging packages to populate a content delivery portal where the search function is used to find the metadata-enriched information, then these semantic quibbles might well be irrelevant.

The situation is different for more complex application scenarios. When metadata transports a large amount of knowledge about individual components and their states that define the overall state of, for example, a machine, it is important to know exactly what is behind a metadatum. If, for example, the weight of a machine is to be derived from its components, then it must be clear whether this is the designation of a product variant from marketing or a component from PIM (product information management).

Top-level ontologies: commonality through an upper structure

How can this room for interpretation be reduced and ambiguity avoided? To make two ontologies say and mean the same thing, you can create a common superstructure that both ontologies relate to. This common superstructure of ontologies is known as a top-level ontology (TLO) or upper ontology. Upper ontologies provide generic, general concepts. Let us introduce you to some initiatives for upper ontologies and some top-level ontologies that have already been developed.

OntoCommons Initiative

Industrial ontologies are the focus of the OntoCommons (Ontology-Driven Data Documentation for Industry Commons) initiative funded by EU Horizon 2020. Ontology experts share ideas in webinars, workshops, and working groups with the goal of creating a framework for integrating ontologies. This framework makes use of established top-level ontologies.

Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE)

An example of a top-level ontology supported by OntoCommons is DOLCE which tries to capture the concepts behind natural language. The central distinguishing feature of the concepts is the dimension of time. For example, all concepts with temporal elements are perdurants, while all concepts without temporal elements are endurants. A soccer game would be a perdurant whereas a soccer ball would be an endurant.

Example of a top-level ontology: DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering)

Basic Formal Ontology (BFO)

Another example of a top-level ontology is Basic Formal Ontology (BFO). BFO is very widely used and has found its way into standardization with ISO/IEC 21838-2:2021. It is very well documented and the basis for many ontologies in the area of life sciences. BFO is also part of the OntoCommons framework for integrating European ontologies. As DOLCE, it distinguishes concepts within the temporal dimension.

Example of a top-level ontology: Basic Formal Ontology (BFO)

Benefits and drawbacks of top-level ontologies

To what extent can top-level ontologies facilitate data exchange? One of the main benefits of top-level ontologies is that they reduce ambiguity. Sorting your own metadata into top-level categories makes it easier to compare it with metadata from other systems. Is my concept a material item, a quality, or even a temporal process? These questions can be answered when metadata is integrated into a top-level ontology.

Another benefit of using top-level ontologies is establishing best practices of ontology modeling. In orientating to TLOs, a uniformity is brought into your own projects. This makes the data more reusable and easier to link to other data. This meets the criteria of, for example, the GO FAIR initiative, under which data should be Findable, Accessible, Interoperable and Reusable.

Work on metadata models can be improved by applying top-level ontologies, for example, to create guidelines for ontology development and to implement the FAIR principles mentioned above. An example of this is the Simple Knowledge Organization System (SKOS), in which metadata is enriched with additional information, such as the description of terminological aspects ("preferred label", "alternative label", "definition", and "example").

SKOS: example with enriched information on terminologies

But: top-level ontologies initially require additional effort and, depending on the perspective, can also increase complexity.

What is iiRDS’ position on top-level ontologies?

In the world of top-level ontologies, iiRDS has the role of a mid-level ontology. In turn, the iiRDS metadata from the iiRDS machinery and software domains represent domain-level vocabulary, meaning they are even more specific. The iiRDS consortium is currently working on aligning iiRDS with the top-level ontology BFO. This limits the scope for interpretation and reduces misunderstandings. 

iiRDS’ position within the ontology hierarchy

Diversity through top-level ontologies

Besides reducing ambiguities, using top-level ontologies allows us to tap into other valuable resources. If it is clear what is being talked about and what concepts mean, then metadata from different sources can be integrated more easily. Below are some examples that are relevant for iiRDS.

Industrial Ontology Foundry (USA)

iiRDS provides a metadata vocabulary for exchanging technical documentation. But specific metadata in the production world is not part of iiRDS. The Industrial Ontology Foundry (IOF) attempts to fill this gap. The IOF is a US consortium dedicated to creating ontologies for digital production. These ontologies are aligned with BFO as a top-level ontology. For example, metadata vocabulary for maintenance can be found in the IOF ontologies.

Ontology of IOF based on the top-level ontology of BFO (highlighted in white) plus maintenance classes highlighted in gray

Common Core Ontology (USA)

Also enriching for iiRDS projects can be the ontologies of the Common Core Ontology (CCO) initiative. The US project also uses the top-level ontology BFO. CCO starts where iiRDS has so far ended: with cross-domain vocabulary, such as geographic location and modeling of points in time and time periods. CCO is used in the medical-pharmaceutical domain for drug development, for example.

Application of BFO’s top-level ontology by the Common Core Ontology (USA)

Conclusion and outlook

Using a common metadata vocabulary facilitates the exchange of information. But misunderstandings can arise when the concepts of the metadata vocabulary are interpreted and brought to life. The scope for interpretation can be reduced by using top-level ontologies. Existing concepts can be effectively sorted into the very basic concepts of top-level ontologies. The clear distinctions between the concepts of the top-level ontology make it easier to understand your own concepts. This will hopefully also make iiRDS easier to use.

parson’s iiRDS expertise

Want to align your documentation strategy with digitalization and Industry 4.0? Benefit from our experience with iiRDS and intelligent information.

Find out more and get in touch.

Add new comment

Your email address will not be published.

You might also be interested in

Ten questions about iiRDS

by on November 20, 2024

Two founding members of the iiRDS Consortium explain the importance and potential of iiRDS and its integration at Endress+Hauser. An interview with Thomas Ziesing from Endress+Hauser and iiRDS consultant Ulrike Parson from parson. Interview: Susanne Lohmüller  more...

Technical documentation – why it matters and how to create it

by parson on August 20, 2024

For suppliers and for users of technical equipment, processes, or systems, technical documentation is critical f. But what exactly is technical documentation? When do we need it and when is it even mandatory? How can you efficiently create high-quality technical documentation as a manufacturer? This article will answer these questions. more...