What is an ontology? And do I need one?

Ontology is originally a term from philosophy and can be translated from Greek as the "doctrine of being". In computer science, however, we use it to refer to formal representation systems.

In systems engineering, we have to deal with the terminology, because the terms are ultimately the foundation for communication between the stakeholders. Whether a simple glossary is sufficient or a formal terminology analysis is required ultimately depends on the system to be developed. But we must consider the topic in some form. The options available are discussed below.

Why an ontology?

One Ontology is an ordered set of concepts, their meaning and relationships to each other. For example, when we talk about a "bank", the ontology helps us to decide whether we are talking about finances or a place to sit. This is, of course, a simple example. Many terms can have an unexpected meaning in a technical context. A "Mirror" has a very specific meaning in architecture, shipbuilding, biology, medicine and many other domains.

In systems engineering, we have to deal with many stakeholders from different specialist areas. For this reason, an ontology can make a major contribution to the success of a project by preventing misunderstandings at an early stage. How we can create such an ontology is of course another question, but more on that in a moment.

The semantic web

In the 2000s, a lot of research was carried out on ontologies, triggered by the success of the World Wide Web (WWW). The WWW suddenly made distributed, structured information in machine-readable form possible. However, this structure was syntactic, not semantic: a machine could easily determine what the title of a web page was and how many headings there were (Syntax). But this said nothing about the meaning (Semantics). The aim of the Semantic Web was to provide the WWW with semantic information to expand.

The above is relevant for systems engineering insofar as these activities result in the Formal conceptual analysis has developed. Many of the methods, notations and tools identified can be useful in systems engineering. For example, the Web Ontology Language (OWL) is a formal description language for ontologies. It is possible to integrate an OWL specification into a UML-class diagram. Which brings us to the world of systems engineering and MBSE would have arrived.

3 Approaches to an ontology in systems engineering

Now the question arises: How do we use an ontology in systems engineering in a meaningful way? There are different approaches, three of which I would like to present:

A simple yet very effective technique is to create and maintain a glossary. The advantage is that this does not require any complex tools or knowledge. However, there are many traps that teams can fall into. For example, if the scope is not clearly defined, there can be long discussions about the content without any real progress being made. In addition, the glossary is often not sufficiently maintained and can therefore be incomplete and/or outdated. And finally: Since the glossary is usually a separate document, there is no Traceability to the system description. This in turn can lead to the specification not adhering to the terminology defined in the glossary.

If modeling is carried out in a team, the ontology can also be represented as a model. In SysML, concepts are modeled as blocks or as classes in UML. With these modeling languages, we are much more expressive and can also represent and differentiate the relationships.

The prerequisite is that the modelers have an appropriate command of the modeling language and that the team can read the models. If the organization operates genuine MBSE, then the domain model is part of the system description. This would also ensure traceability to the specification. However, not many teams have this level of maturity today. But even then, the ontology can be created and maintained in this form, just without full traceability.

This approach is not for the faint-hearted: The approach described under 2. makes clever use of the structures of UML and SysML. However, there are also formal descriptions from formal concept analysis. Ultimately, we are again dealing with concepts that have relationships and properties. But with an appropriate theoretical foundation, statements can be made about completeness, for example. But, to be honest, I have only come across these approaches in an academic context so far.

Neglected ontologies?

During my research, I was a little surprised at how few tools seem to help with maintaining an ontology. Although many requirements management tools have the option of creating a glossary, it is still difficult to maintain. For example, all tools allow links to requirements, but not to individual words. Individual words can be hyperlinked, but then the traceability analysis is missing (and renaming is also not automatically maintained).

Still the most powerful tool seems to be Visual Paradigm which enables the manual extraction of a glossary from textual requirements. But here, too, I miss the dynamics and maintenance over a longer period of time.

Have I overlooked a practical option for managing an ontology? Then please let me know in the comments section.

Image by Gerd Altmann from Pixabay