Ontologien: Begriffe und Beziehungen formal beschreiben

Was sind Ontologien in der Informatik?

Für ein Begriffsmodell müssen Fachverantwortliche bestimmen, welche Arten von Dingen zur betrachteten Domäne gehören und welche Beziehungen zwischen ihnen gelten. Feldnamen allein reichen dafür nicht: Auch die zulässigen Schlüsse aus den Aussagen brauchen eine festgelegte Bedeutung.

Für einen Produktionskontext können etwa die Klassen „Produkt“, „Materialcharge“, „Aufgabe“, „Messung“ und „SOP-Version“ relevant sein. Eine Ontologie kann zusätzlich ausdrücken, dass jede Materialcharge eine Charge ist, dass eine Aufgabe Material verwendet oder ein Zwischenprodukt erzeugt und dass eine Messung einen Wert sowie eine Einheit besitzt. Solche Aussagen bilden ein gemeinsames Vokabular, das nicht allein von Feldnamen oder der Logik einer einzelnen Anwendung abhängt.

Der OWL-2-Primer des W3C beschreibt eine Ontologie als Menge präziser Aussagen über einen betrachteten Ausschnitt der Welt. OWL 2 stellt dafür Klassen, Eigenschaften, Individuen und Datenwerte bereit. Die Bedeutung der Aussagen ist formal definiert, sodass geeignete Programme Konsistenz prüfen und implizite Informationen ableiten können.^[1]

Eine Ontologie ist damit weder ein bloßes Glossar noch automatisch ein vollständiges Abbild der Wirklichkeit. Sie ist ein bewusst entwickeltes Modell. Seine Qualität hängt davon ab, ob Begriffe fachlich richtig gewählt, Grenzen transparent gesetzt und Änderungen kontrolliert gepflegt werden.

Beispiel: Begriffe entlang eines Chargenprozesses verbinden

Ein vereinfachtes, fiktives Begriffsmodell legt fest: Jede Materialcharge ist eine Charge. Für das konkrete Objekt M-204 ist angegeben, dass es eine Materialcharge ist. Aus der Unterklassenbeziehung folgt damit auch, dass M-204 eine Charge ist. Eine Abfrage nach Chargen kann diese abgeleitete Zugehörigkeit berücksichtigen, wenn die entsprechenden Schlussfolgerungen ausgewertet werden.

Die Umkehrung ist nicht erlaubt: Ist P-31 lediglich als Charge beschrieben, folgt daraus nicht, dass P-31 eine Materialcharge ist. Ebenso lässt sich aus der Zugehörigkeit zur Klasse Charge keine Freigabe ableiten. Dafür wären weitere Aussagen und gegebenenfalls passende Axiome erforderlich.

Angenommen, das Modell erklärt Materialcharge und Gerät außerdem als disjunkte Klassen. Wird M-204 beiden Klassen zugeordnet, widersprechen sich diese Aussagen unter den gesetzten Axiomen. Der Widerspruch zeigt, dass Daten oder Modellierung geprüft werden müssen; er entscheidet nicht, welche Zuordnung die betriebliche Wirklichkeit richtig wiedergibt.

Andere Axiome können etwa inverse Eigenschaften oder ausgeschlossene Klassenzugehörigkeiten beschreiben. Eine solche Festlegung muss zur Domäne passen: Ob eine Beziehung transitiv ist, lässt sich nicht aus ihrem alltagssprachlichen Namen allein ableiten.

Das Beispiel beschreibt die Rolle formaler Aussagen: Sie machen bestimmte Schlüsse möglich und andere unzulässig. Weder die tatsächliche Identität von M-204 noch seine Freigabe wird dadurch ohne passende Erfassung und fachliche Prüfung festgestellt.

Fehlende Aussage bedeutet nicht automatisch „falsch“

OWL arbeitet grundsätzlich unter der Open-World-Annahme. Ist eine Information nicht vorhanden, gilt sie nicht automatisch als falsch; sie kann schlicht unbekannt sein.^[1] Das unterscheidet ontologisches Schließen von vielen Datenbank- und Geschäftsregeln, die eine abgeschlossene Datenbasis voraussetzen.

Fehlt beispielsweise die Aussage, dass Charge M-204 freigegeben ist, darf ein OWL-Reasoner daraus nicht allein ableiten, dass die Charge gesperrt ist. Es ist möglich, dass der Freigabestatus noch nicht erfasst wurde. Für einen operativen Prozess kann genau diese Unterscheidung entscheidend sein: „nicht freigegeben“, „Freigabe unbekannt“ und „Freigabe nicht erforderlich“ sind drei verschiedene Zustände.

Auch unterschiedliche Namen müssen nicht automatisch unterschiedliche Dinge bezeichnen. Zwei Identifikatoren können dasselbe reale Objekt meinen, sofern ihre Verschiedenheit nicht ausdrücklich feststeht. Umgekehrt dürfen gleich klingende Begriffe nicht ungeprüft zusammengeführt werden. Identität benötigt deshalb eigene fachliche Regeln und stabile Kennzeichnungen.

Die offene Welt ist kein Mangel der Ontologie, sondern Teil ihrer Semantik. Sie eignet sich für verteiltes Wissen, das erweitert werden kann. Für vollständigkeitsabhängige betriebliche Prüfungen braucht es daneben jedoch eine Validierungs- oder Anwendungslogik, die konkret festlegt, welche Angaben in einer bestimmten Situation vorhanden sein müssen.

Schließen ist keine Pflichtfeldkontrolle

Eine Domain- oder Range-Aussage in OWL kann aus einer Beziehung eine Klassenzugehörigkeit ableiten. Sie funktioniert nicht einfach wie eine Eingabemaske, die ein zuvor anders klassifiziertes Objekt zurückweist. Weitere Axiome können einen Widerspruch ergeben; das ist eine andere Frage als das Vorhandensein eines Pflichtfelds.[1]

SHACL kann einen konkreten RDF-Datenbestand gegen vorgegebene Bedingungen prüfen.[4] Die Anwendung muss zusätzlich bestimmen, welche Folge ein Befund hat. Weder ein logischer Schluss noch ein Strukturbericht erteilt von selbst eine betriebliche Freigabe.

Die grundlegenden Bausteine

Ontologien bauen auf wenigen Grundelementen auf, die gemeinsam ein ausdrückbares Modell ergeben:

Klassen sind keine Ordner, in denen Datensätze physisch abgelegt werden. Sie beschreiben Mengen von Individuen mit gemeinsamer Bedeutung. Ein Individuum kann mehreren Klassen angehören: Eine konkrete Charge kann zugleich „Materialcharge“, „gesperrtes Objekt“ und „prüfpflichtiger Bestand“ sein. Die Mitgliedschaften schließen sich nicht automatisch gegenseitig aus.

Eigenschaften verbinden Individuen miteinander oder ordnen ihnen Werte zu. OWL unterscheidet dafür unter anderem Objekt- und Dateneigenschaften. „Aufgabe verwendet Charge“ verbindet zwei Individuen. „Messung hat Zahlenwert 7,2“ verbindet ein Individuum mit einem Datenwert.

RDF Schema stellt bereits Begriffe für Klassen, Unterklassen, Eigenschaften, Domänen und Wertebereiche bereit.^[3] OWL 2 erweitert die Ausdrucksmöglichkeiten unter anderem um Äquivalenz, Ausschluss, Eigenschaftsmerkmale, komplexe Klassenbeschreibungen und Kardinalitäten.^[2] Wie viel Formalisierung sinnvoll ist, hängt vom Anwendungsfall ab. Ein kleines, verständliches Modell kann belastbarer sein als eine umfangreiche Ontologie, deren Aussagen niemand mehr sicher beurteilt.

Ontologie, Taxonomie, Datenmodell und Knowledge Graph

Mehrere Modellarten ordnen Informationen, lösen aber unterschiedliche Aufgaben. Eine Taxonomie strukturiert Begriffe typischerweise hierarchisch. Sie kann beispielsweise „Rohstoff“, „Zwischenprodukt“ und „Fertigprodukt“ unter dem Oberbegriff „Materialobjekt“ einordnen. Das unterstützt Navigation und Klassifikation, beschreibt jedoch noch nicht alle fachlichen Beziehungen.

Ein Datenmodell definiert, welche Strukturen eine Anwendung speichert: Tabellen, Felder, Datentypen, Schlüssel und technische Abhängigkeiten. Es kann präzise festlegen, dass ein Feld batch_id erforderlich ist. Ob eine Charge fachlich dasselbe meint wie ein Los, wann sie als freigegeben gilt oder welche Rolle eine Freigabe erteilen darf, bleibt ohne zusätzliche Semantik häufig in Programmcode, Dokumentation oder menschlichem Wissen verborgen.

Eine Ontologie richtet den Blick auf Bedeutung. Klassen ordnen Dinge ein, Eigenschaften beschreiben Beziehungen oder Werte, und Axiome formulieren allgemeine Aussagen über die Domäne. Sie kann festhalten, dass jede freigegebene Materialcharge eine geprüfte Materialcharge ist oder dass „verwendet Material“ die umgekehrte Richtung von „wird verwendet in“ besitzt. Derartige Aussagen lassen sich unabhängig von einer konkreten Bildschirmmaske oder Tabellenstruktur verwenden.

Knowledge Graphs verbinden Aussagen über Entitäten: Aufgabe A-17 verwendet Charge M-204; Messung P-91 gehört zu dieser Aufgabe; Person R-8 hat sie geprüft. Eine Ontologie kann die verwendeten Begriffe und Beziehungen formal beschreiben. Sie darf selbst auch Aussagen über einzelne Objekte enthalten. Die Unterscheidung verläuft deshalb nicht strikt zwischen Instanzdaten und Begriffen: Hier steht die formale Bedeutung im Vordergrund, beim Knowledge Graph das verknüpfte Wissen und seine Nutzung.

Ontologien brauchen fachliche Verantwortung und Versionen

Eine belastbare Ontologie entsteht nicht durch das Sammeln möglichst vieler Begriffe. Ausgangspunkt sind konkrete Fragen: Welche Objekte müssen über Systemgrenzen hinweg eindeutig erkannt werden? Welche Beziehungen werden für Prüfungen oder Auswertungen benötigt? Wo führen unterschiedliche Bezeichnungen heute zu Missverständnissen?

Fachverantwortliche und technische Modellierer müssen Begriffe gemeinsam abgrenzen. Für jede Klasse und Eigenschaft sind verständliche Definitionen, Beispiele und Gegenbeispiele hilfreich. Testdaten zeigen, ob die vorgesehenen Schlüsse tatsächlich entstehen und ob unbeabsichtigte Aussagen möglich werden. Reasoner unterstützen bei Konsistenzprüfungen, ersetzen aber keine fachliche Freigabe.

Ändert sich ein Begriff, kann dies Abfragen, Integrationen und Regeln beeinflussen. Ontologien benötigen deshalb Versionierung, Änderungsgründe und eine Migrationsstrategie. Neue Begriffe sollten ergänzt werden können, ohne die Bedeutung historischer Daten stillschweigend umzudeuten. Veraltete Begriffe können als solche gekennzeichnet und kontrolliert auf Nachfolger bezogen werden.

Operative Wissensmodelle gehen einen Schritt weiter: Sie verbinden Begriffe und Beziehungen mit Gültigkeit, Prozesszuständen und konkreten Wirkungspunkten während der Arbeit. Eine Ontologie kann dafür einen formalen semantischen Baustein liefern. Die operative Nutzung muss zusätzlich festlegen, wann welches Wissen für welche Aufgabe herangezogen wird.

Was Ontologien nicht leisten

Eine Ontologie macht falsche Eingangsdaten nicht wahr. Sie kann Widersprüche sichtbar machen oder zusätzliche Aussagen ableiten, sofern die dafür nötigen Axiome vorhanden sind. Ob ein Messwert korrekt erfasst wurde, eine Probe repräsentativ war oder eine Person eine Aufgabe tatsächlich ausgeführt hat, lässt sich nicht allein aus dem Begriffsmodell entscheiden.

Auch gemeinsames Vokabular führt nicht automatisch zu funktionierender Integration. Identifikatoren müssen zugeordnet, Formate übertragen, Versionen abgestimmt und Verantwortlichkeiten geregelt werden. Für semantische Interoperabilität müssen die beteiligten Systeme die ausgetauschten Angaben in derselben fachlichen Bedeutung verwenden. Eine Ontologie kann dazu beitragen, löst aber nicht sämtliche Integrationsaufgaben.

Zu starke Formalisierung kann zudem unnötige Komplexität erzeugen. Jede zusätzliche Regel erweitert nicht nur die Ausdruckskraft, sondern auch Prüf-, Pflege- und Erklärungsbedarf. Für operative Systeme ist deshalb entscheidend, nur solche Axiome einzuführen, deren fachliche Bedeutung verstanden und deren Auswirkungen getestet sind.

Schließlich bildet jede Ontologie nur eine Perspektive auf einen abgegrenzten Bereich. Begriffe können je nach Markt, Produkt, Prozess oder regulatorischem Kontext unterschiedlich verwendet werden. Diese Grenzen sollten dokumentiert sein, statt eine universelle Gültigkeit zu unterstellen.

Ein Gegenbeispiel prüft die Grenze des Axioms

Ein Gegenbeispiel zeigt, ob das Modell auch dort die beabsichtigte Grenze zieht, wo ein naheliegender Schluss unzulässig wäre.

Eine nützliche Ontologie macht solche Unterschiede prüfbar. Zu ihren Axiomen gehören deshalb verständliche Beispiele und Gegenbeispiele sowie eine kontrollierte Pflege. So kann formale Präzision helfen, unbeabsichtigte Schlüsse zu erkennen, bevor Anwendungen darauf aufbauen.