Was ist eine Ontologie? Und brauche ich eine?

Ontologie ist ursprünglich ein Begriff aus der Philosophie und kann aus dem Griechischen übersetzt werden mit der „Lehre des Seins“. In der Informatik hingegen meinen wir damit formale Repräsentationssysteme.

Im Systems Engineering müssen wir uns mit den Begrifflichkeiten auseinandersetzen, denn die Begriffe sind schließlich das Fundament für die Kommunikation zwischen den Stakeholdern. Ob ein einfacher Glossar reicht, oder eine formale Begriffsanalyse erforderlich ist, hängt letzten Endes vom zu entwickelnden System ab. Aber in irgendeiner Form müssen wir das Thema berücksichtigen. Welche Optionen es gibt wird im Folgenden diskutiert.

Warum eine Ontologie?

Eine Ontologie ist eine geordnete Menge von Begriffen, deren Bedeutung und Beziehungen zueinander. Wenn wir zum Beispiel von einer „Bank“ sprechen, hilft uns die Ontologie zu entscheiden, es um Finanzen geht oder um eine Sitzgelegenheit. Das ist natürlich ein einfaches Beispiel. Viele Begriffe können im fachlichen Kontext eine unerwartete Bedeutung haben. Ein „Spiegel“ hat in Architektur, Schiffbau, Biologie und Medizin und vielen anderen Domänen eine sehr spezifische Bedeutung.

Im Systems Engineering haben wir es mit vielen Stakeholdern aus unterschiedlichen Fachbereichen zu tun. Aus diesem Grund kann eine Ontologie einen großen Beitrag zum Projekterfolg leisten, da Missverständnisse frühzeitig verhindert werden. Wie wir so eine Ontologie schaffen können ist natürlich eine andere Frage, doch dazu gleich mehr.

Das Semantische Web

In den 2000ern wurde viel Forschung zu Ontologien betrieben, ausgelöst durch den Erfolg des World Wide Webs (WWW). Das WWW machte plötzlich verteilte, strukturierte Information in maschinenlesbarer Form möglich. Allerdings war diese Struktur syntaktischer, nicht semantischer Art: Eine Maschine konnte leicht feststellen, was der Titel einer Webseite war und wie viele Überschriften vorhanden sind (Syntax). Aber dies sagte nichts über die Bedeutung aus (Semantik). Ziel des Semantischen Webs war es, das WWW mit semantischen Informationen zu erweitern.

Das Gesagte ist für das Systems Engineering insofern relevant, da sich aus diesen Aktivitäten die formale Begriffsanalyse entwickelt hat. Viele der identifizierten Methoden, Notationen und Werkzeuge können im Systems Engineering Nützlich sein. Zum Beispiel gibt es mit der Web Ontology Language (OWL) eine formale Beschreibungssprache für Ontologien. Es ist möglich, eine OWL-Spezifikation in ein UML-Klassendiagramm zu transformieren. Womit wir in der Welt des Systems Engineering und MBSE angekommen wären.

3 Ansätze einer Ontologie im Systems Engineering

Nun stellt sich die Frage: Wie setzen wir eine Ontologie im Systems Engineering sinnvoll ein? Da gibt es unterschiedliche Ansätze, von denen ich drei vorstellen möchte:

Eine einfache und dennoch sehr effektive Technik ist es, einen Glossar zu erstellen und zu pflegen. Der Vorteil ist, dass dies keine komplexen Werkzeuge oder Kenntnisse erfordert. Allerdings gibt es hier viele Fallen, in die Teams geraten können. Wenn bspw. der Scope nicht sauber abgegrenzt ist, kann es lange Diskussionen um den Inhalt geben, ohne wirklich voranzukommen. Außerdem wird der Glossar oft nicht ausreichend gepflegt und kann daher unvollständig und/oder veraltet sein. Und zuletzt: Da der Glossar in der Regel ein separates Dokument ist, gibt es keine Nachverfolgbarkeit zur Systembeschreibung. Das wiederum kann dazu führen, dass die Spezifikation sich nicht an die im Glossar definierte Terminologie hält.

Wenn im Team Modellierung betrieben wird, dann kann die Ontologie auch als Modell dargestellt werden. In der SysML werden Konzepte als Blöcke modelliert oder als Klassen in UML. Mit diesen Modellierungssprachen sind wir wesentlich ausdrucksstärker und können auch die Beziehungen darstellen und differenzieren.

Voraussetzung ist, dass die Modellierer die Modellierungssprache entsprechend beherrschen und das Team die Modelle lesen kann. Wenn die Organisation echtes MBSE betreibt, dann ist das Domänenmodell Teil der Systembeschreibung. Dadurch wäre auch eine Nachverfolgbarkeit zur Spezifikation gegeben. Allerdings haben nicht viele Teams heute schon diese Reife. Doch auch dann kann die Ontologie in dieser Form erstellt und gewartet werden, nur eben ohne die volle Traceability.

Dieser Ansatz ist nichts für schwache Nerven: Der unter 2. beschriebene Ansatz nutzt geschickt die Strukturen von UML und SysML. Es gibt aber auch formale Beschreibungen aus der formalen Begriffsanalyse. Letzen Endes haben wir es auch hier wieder mit Konzepten zu tun, die Beziehungen und Eigenschaften haben. Doch mit einem entsprechenden theoretischen Unterbau können bspw. Aussagen über die Vollständigkeit gemacht werden. Aber, ehrlich gesagt, bin ich diesen Ansätzen bisher nur im akademischen Kontext begegnet.

Vernachlässigte Ontologien?

Ich war doch bei der Recherche ein bisschen überrascht, wie wenig Werkzeuge bei der Pflege einer Ontologie zu helfen scheinen. Viele Anforderungsmanagementwerkzeuge haben zwar die Möglichkeit Einen Glossar anzulegen, doch die Pflege fällt trotzdem schwer. Zum Beipiel ermöglichen alle Werkzeuge die Verlinkung zu Anforderungen, jedoch nicht zu einzelnen Worten. Einzelne Worte können zwar per Hyperlink verlinkt werden, doch dann fehlt die Traceability-Analyse (und bei Umbenennungen wird ebenfalls nicht automatisch gepflegt).

Noch das leistungsfähigste Werkzeug scheint Visual Paradigm zu sein, welches die händische Extraktion eines Glossars aus textuellen Anforderungen ermöglicht. Doch auch hier fehlt mir die Dynamik und Pflege über einen längeren Zeitraum.

Habe ich eine praxisnahe Option für das Management einer Ontologie übersehen? Dann bitte im Kommentarbereich Rückmeldung geben.

Image by Gerd Altmann from Pixabay