Knowledge Graphs: Daten, Beziehungen und Kontext als Wissensnetz

Was sind Knowledge Graphs?

Die wissenschaftliche Literatur verwendet keine vollständig einheitliche Definition. Hogan et al. fassen einen Knowledge Graph bewusst weit als Datengraphen auf, der Wissen über die reale Welt sammelt und vermittelt. Seine Knoten stehen für relevante Entitäten, seine Kanten für Beziehungen zwischen ihnen.^[1] Entscheidend ist damit nicht eine bestimmte Software oder Schreibweise. Entscheidend ist die explizite Verbindung von Daten, Beziehungen und Bedeutung.

Ein Knowledge Graph ist folglich mehr als eine grafische Darstellung vorhandener Tabellen. Er bildet einen fachlichen Zusammenhang so ab, dass einzelne Aussagen miteinander verknüpft, über mehrere Quellen hinweg eingeordnet und gezielt abgefragt werden können.

Vom Material über seine Verwendung zur Produktcharge

Ein fiktiver Abfrageauftrag lautet: Welche Produktchargen wurden unter Verwendung der Materialcharge M-204 bearbeitet? Der Graph benötigt dafür mehr als eine Liste gleich benannter Materialien. Er muss die konkrete Materialidentität mit ihren Verwendungen und den betroffenen Produktchargen verbinden.

Ein möglicher Pfad führt von M-204 zur Aufgabe A-17 und von A-17 zur Produktcharge C-24. Die Beziehung zur Materialcharge heißt „verwendet“, die zur Produktcharge „bearbeitet“. Eine weitere Aufgabe A-18 kann dasselbe Material für C-25 verwenden. Die Abfrage folgt diesen Beziehungen und liefert die so verbundenen Produktchargen.

Ein Bezug „vorgesehenes Material“ würde eine andere Aussage tragen. Ebenso kann C-24 über mehrere Aufgaben erreichbar sein. Soll jede betroffene Produktcharge nur einmal erscheinen, muss die Abfrage ihre Identität entsprechend berücksichtigen. Das Ergebnis hängt somit von Beziehungsbedeutung und Abfrageregel ab.

Der Pfad beschreibt eine Verwendung, keine bewiesene Fehlerursache. Wird M-204 später untersucht, können die gefundenen Chargen einen Ausgangspunkt für weitere Prüfungen bilden. Ob sie tatsächlich betroffen sind, ist eine zusätzliche fachliche Frage.

Knoten, Kanten und Aussagen

Das Grundprinzip lässt sich als Aussage in drei Teilen lesen:

Ein einfaches Beispiel lautet: „Aufgabe 4711 verwendet Materialcharge M-204.“ Die Aufgabe ist das Subjekt, „verwendet“ die Beziehung und die Materialcharge das Objekt. Weitere Aussagen können denselben Knoten ergänzen: Die Aufgabe folgt SOP-Version 7, findet in Raum R-12 statt, wird von Rolle Produktion ausgeführt und erzeugt den Messwert W-88.

RDF, das Resource Description Framework des W3C, formalisiert ein solches Grundmuster als Subjekt-Prädikat-Objekt-Tripel. Eine Menge dieser Tripel bildet einen RDF-Graphen. Das W3C beschreibt ihn als gerichtetes Knotenkanten-Diagramm; Identifikatoren, Literale und unbenannte Knoten können dabei unterschiedliche Funktionen übernehmen.^[2]

Knowledge Graphs müssen nicht zwingend RDF verwenden. Auch Property-Graph-Modelle können Knoten und Kanten um Eigenschaften ergänzen. Die Wahl des Modells hängt von den benötigten Abfragen, Integrationen und Werkzeugen ab.^[1] RDF ist hier deshalb wichtig, weil es ein standardisiertes Beispiel für die explizite Beschreibung von Ressourcen und Beziehungen liefert - nicht weil jeder Knowledge Graph technisch identisch aufgebaut sein muss.

Identität verbindet dieselben realen Objekte

Ein Graph wird erst verlässlich, wenn klar ist, welcher Knoten welches reale Objekt bezeichnet. Dieselbe Materialcharge kann im Einkauf, Lager, Produktionsauftrag und Prüfbericht unterschiedlich benannt sein. Werden diese Bezeichnungen ungeprüft als vier Objekte behandelt, entsteht kein zusammenhängendes Bild. Werden dagegen verschiedene reale Chargen fälschlich zusammengeführt, werden Aussagen unzutreffend verbunden.

RDF verwendet IRIs als global gedachte Identifikatoren. Zwei Vorkommen derselben IRI bezeichnen grundsätzlich dieselbe Ressource.^[2] Innerbetriebliche Knowledge Graphs können andere Identifikationsverfahren nutzen. Das fachliche Problem bleibt gleich: Identitäten benötigen stabile Regeln, eindeutige Schlüssel und eine kontrollierte Zuordnung zwischen Quellsystemen.

Die Auflösung von Identität ist deshalb keine kosmetische Datenbereinigung. Sie entscheidet darüber, ob Fragen über Systemgrenzen hinweg sinnvoll beantwortet werden können. Eine korrekte Verknüpfung erlaubt etwa, den Einkauf einer Materialcharge mit ihrem Lagerzugang, ihrem tatsächlichen Verbrauch und den daraus entstandenen Produktzuständen zu verbinden.

Warum isolierte Datensätze nicht genügen

Eine Chargennummer, ein Verbrauchswert oder ein Prüfergebnis kann für sich genommen korrekt sein und trotzdem wenig erklären. Der Informationswert entsteht erst durch Kontext: Zu welchem Produkt gehört die Charge? Bei welcher Aufgabe wurde das Material verbraucht? Welche SOP-Version galt? Wer führte den Schritt aus, wer prüfte ihn und welche Freigabe folgte?

Auch relationale Datenmodelle können fachliche Beziehungen explizit abbilden und über Schlüssel verknüpfen. Problematisch wird es, wenn Identitäten oder Bedeutungen zwischen Datenbeständen nicht abgestimmt sind. Ein Knowledge Graph bietet dafür eine graphbasierte Darstellung: Objekte und benannte Beziehungen bilden Pfade, entlang derer sich zusammenhängende Aussagen abfragen lassen. Die fachliche Bedeutung muss auch hier bewusst modelliert werden.

Das ist besonders relevant, wenn Daten aus mehreren Bereichen zusammengeführt werden. Hogan et al. nennen Schema, Identität und Kontext als zentrale Aufgaben beim Aufbau eines Knowledge Graph: Ein Schema beschreibt die übergeordnete Struktur, Identität klärt, welche Bezeichnungen dasselbe reale Objekt meinen, und Kontext grenzt ein, unter welchen Umständen eine Aussage gilt.^[1]

Kontext verhindert zu starke Aussagen

Eine Beziehung kann ohne ihren Geltungsrahmen missverständlich sein. „Charge A ist freigegeben“ bleibt unvollständig, wenn nicht erkennbar ist, für welchen Prozessstand, Markt, Prüfentscheid oder Zeitpunkt die Aussage gilt. Auch Zuständigkeiten, SOP-Versionen und Grenzwerte verändern sich.

Ein Knowledge Graph muss daher nicht nur Beziehungen speichern, sondern bei Bedarf auch den Kontext einer Aussage modellieren. Dafür kommen beispielsweise benannte Graphen, eigenständige Ereignis- oder Entscheidungsobjekte, Zeitangaben und Verweise auf die zugrunde liegende Quelle in Betracht. RDF selbst ist laut W3C ein atemporales Datenmodell: Ein Graph beschreibt zunächst einen statischen Informationsstand. Zeitliche Aspekte und Ereignisse können zwar mit geeignetem Vokabular ausgedrückt werden, müssen aber ausdrücklich modelliert werden.^[2]

Hier liegt eine wichtige Grenze zur Prozesshistorie. Ein Knowledge Graph kann historische Aussagen und ihre Beziehungen repräsentieren. Er ersetzt jedoch nicht automatisch die Erfassung vollständiger Prozessereignisse oder einen belastbaren Änderungsnachweis.

Erwartete Beziehungen vor der Abfrage prüfen

Für den Pfad über A-17 muss die Aufgabe eine nachvollziehbare Verbindung zum verwendeten Material und zum bearbeiteten Produkt besitzen. Fehlt eine dieser Beziehungen, kann die Abfrage C-24 übersehen. Eine Strukturregel kann genau diese erwarteten Angaben prüfen.

SHACL formuliert solche Bedingungen für RDF-Graphen.[4] Ein bestandener Strukturtest zeigt jedoch nicht, dass A-17 tatsächlich M-204 verwendete. Er kontrolliert die formulierte Erwartung an die gespeicherte Darstellung; die Richtigkeit der Zuordnung benötigt ihre eigene Grundlage.

Schema, Ontologie und konkrete Aussagen

Ein Knowledge Graph kann Aussagen über einzelne Objekte und über allgemeine Begriffe enthalten. Ein Schema beschreibt die vorgesehenen Objektarten und Beziehungen. Diese Ebenen lassen sich unterscheiden, ohne sie technisch vollständig voneinander zu trennen. Es kann beispielsweise festlegen, dass eine Aufgabe eine SOP-Version verwendet, eine Materialcharge verbraucht und von einer Rolle ausgeführt wird.

Ontologien können dieses Begriffs- und Beziehungsmodell formal präzisieren. OWL 2 ist nach der W3C-Spezifikation eine deklarative Sprache zur Beschreibung von Ontologien. Sie kann Begriffe, Zusammenhänge und logische Aussagen so ausdrücken, dass Software daraus weitere Informationen ableiten kann. Eine OWL-Ontologie kann neben allgemeinen Begriffen auch Aussagen über konkrete Individuen enthalten.^[3]

Nicht jeder Knowledge Graph benötigt eine umfangreiche Ontologie. Für einen begrenzten Anwendungsfall kann ein einfaches, kontrolliertes Schema ausreichen. Formale Regeln werden dort wertvoll, wo Begriffe über Systeme hinweg eindeutig verstanden, Widersprüche erkannt oder Schlussfolgerungen reproduzierbar abgeleitet werden sollen. Die Entwicklung eines solchen formalen Begriffsmodells ist jedoch eine eigene Aufgabe und nicht mit dem bloßen Aufbau eines Graphen erledigt.

Von strukturierten Daten zu auswertbarem Zusammenhang

Knowledge Graphs erzeugen fehlende Betriebsdaten nicht von selbst. Sie benötigen strukturierte, identifizierbare Eingaben. Freitext kann Hinweise liefern, doch verlässliche Beziehungen entstehen erst, wenn relevante Objekte, Ereignisse, Rollen und Zustände eindeutig erfasst oder kontrolliert aus Quellen extrahiert werden.

Auch ein Graph ersetzt nicht jede bestehende Datenstruktur. Mengenbuchungen, Messreihen oder Dokumentdateien können weiterhin in spezialisierten Systemen liegen. Der Knowledge Graph kann ihre Identität, Bedeutung und Verbindung beschreiben und auf die jeweilige Quelle verweisen. Dadurch entsteht eine semantische Verbindungsschicht, ohne sämtliche Daten in dasselbe Speicherformat zwingen zu müssen.

Für Process Intelligence ist diese Verknüpfung besonders nützlich. Analyseergebnisse lassen sich nicht nur nach Tabellenfeldern gruppieren, sondern entlang fachlicher Beziehungen untersuchen: nach Produkt, Charge, Material, Rolle, Aufgabe, Freigabe oder SOP-Version. Voraussetzung bleibt, dass diese Beziehungen fachlich korrekt modelliert und aus verlässlichen Daten gespeist werden.

Was ein Knowledge Graph leistet - und was nicht

Ein sauber aufgebauter Knowledge Graph kann heterogene Daten in einen gemeinsamen fachlichen Zusammenhang bringen. Er erleichtert Abfragen über Systemgrenzen, macht indirekte Beziehungen sichtbar und schafft eine Grundlage für Suche, Analyse, Assistenz und kontrollierte Schlussfolgerungen. Neue Datenquellen können ergänzt werden, ohne jede bestehende Anwendung auf dasselbe interne Modell umzubauen.

Er ist jedoch weder automatisch vollständig noch objektiv. Modellierungsentscheidungen bestimmen, welche Objekte und Beziehungen sichtbar werden. Identitätsfehler können Daten falsch zusammenführen. Veraltete Aussagen bleiben veraltet, wenn Aktualisierung und Gültigkeit nicht geregelt sind. Logische Ableitungen sind nur so tragfähig wie die zugrunde liegenden Aussagen und Regeln.

Ein Knowledge Graph ist außerdem kein Ersatz für Berechtigungen, Versionierung, Audit Trail, Freigabeverfahren oder fachliche Verantwortung. Er kann deren Zusammenhänge darstellen und für Auswertungen nutzbar machen. Die operativen Kontrollen müssen dennoch in den ausführenden Systemen verankert bleiben.

Ein sinnvoller Graph lässt die Antwort zurückverfolgen

Die Abfrage nach M-204 liefert nicht nur Chargenkennungen. Über die Aufgaben und benannten Beziehungen lässt sich prüfen, weshalb C-24 oder C-25 im Ergebnis erscheinen. Ein fehlender oder falsch bezeichneter Bezug verändert diese Antwort.

Der Nutzen eines Knowledge Graphs zeigt sich deshalb an konkreten Fragen und ihren nachvollziehbaren Pfaden. Identitäten, Beziehungsbedeutung und Geltungsrahmen müssen diese Pfade tragen; die Anzahl gespeicherter Knoten allein sagt darüber wenig aus.