Semantische Interoperabilität: Wenn Systeme Daten gleich verstehen

Bedeutung beim Systemwechsel erhalten

Der European Interoperability Framework von 2017 berücksichtigt dabei Bedeutung und Darstellung der Information.[1] Wie groß der Unterschied zwischen lesbaren Zeichen und gemeinsamer Aussage sein kann, zeigt der Statuswert released im folgenden Austauschfall.

Beispiel: Freigabestatus einer Charge

In einem fiktiven Austauschfall übermittelt ein Produktionssystem eine Charge mit dem Status released. Das Qualitätssystem besitzt ebenfalls einen Wert released. Technisch erscheint die Zuordnung eindeutig. Fachlich können jedoch verschiedene Bedingungen dahinterstehen.

Im Produktionssystem bedeutet der Status möglicherweise, dass alle Fertigungsschritte abgeschlossen wurden. Im Qualitätssystem bezeichnet er die formale Chargenfreigabe nach Prüfung aller Ergebnisse. Ein Planungssystem könnte denselben Begriff wiederum als „für die weitere Bearbeitung verfügbar“ interpretieren.

Semantische Interoperabilität verlangt deshalb mehr als den gemeinsamen Textwert. Das Modell muss klären:

• welcher Freigabetyp gemeint ist,
• auf welches Objekt und welche Version sich die Freigabe bezieht,
• wer oder welche Rolle sie erteilt hat,
• welche Voraussetzungen erfüllt sein mussten,
• zu welchem Zeitpunkt der Status galt und
• ob er später ersetzt, eingeschränkt oder widerrufen wurde.

Erst mit diesem Kontext kann ein empfangendes System entscheiden, ob der Zustand für seine eigene Aufgabe geeignet ist. Eine technische Schnittstelle transportiert die Information. Das semantische Modell macht ihren fachlichen Gehalt nachvollziehbar.

Ein gleich geschriebener Status ist noch kein Mapping

Im Austauschfall darf released aus dem Produktionssystem nicht allein wegen der Schreibweise zur Qualitätsfreigabe im Zielsystem werden. Die erste Zuordnung muss die tatsächliche Aussage erhalten: „Fertigung abgeschlossen“. Erst ein zusätzlicher geeigneter Nachweis könnte eine andere Entscheidung tragen.

Hat das Zielmodell nur die Auswahl „freigegeben“ oder „gesperrt“, fehlt möglicherweise eine benötigte Unterscheidung. Das Mapping muss diesen Verlust kenntlich machen oder den Fall zur Klärung zurückgeben. Eine erzwungene Zuordnung würde die Information verändern.

Zu jeder Zuordnungsregel gehören Quell- und Zieldefinition, Geltungsbereich und Fassung. Ändert ein System die Bedeutung seines Statuswerts, ist die Regel erneut zu prüfen, selbst wenn Feldname und Datentyp identisch bleiben.

Identitäten müssen stabil und zuordenbar sein

Gemeinsame Bedeutung benötigt eindeutige Referenzen. Wenn zwei Datensätze dieselbe Charge betreffen, müssen die Systeme erkennen können, dass beide Kennungen dasselbe reale Objekt bezeichnen. Fehlt diese Zuordnung, entstehen Dubletten oder getrennte Teilbilder eines eigentlich zusammenhängenden Vorgangs.

Eine globale Kennung ist dafür nicht immer erforderlich. Lokale Identifikatoren können genügen, wenn ihr Namensraum, Herausgeber und Geltungsbereich eindeutig sind. Entscheidend ist, dass nicht zufällig gleiche Zeichenfolgen für verschiedene Dinge gehalten werden und dass bewusst unterschiedliche Kennungen auf dasselbe Objekt abgebildet werden können.

RDF verwendet Internationalized Resource Identifiers, kurz IRIs, als global eindeutige Bezeichner in einem Graphdatenmodell. Eine IRI kann auf eine dokumentierte Definition verweisen und damit die beabsichtigte Referenz eines Begriffs sichtbar machen.^[2] Das ist ein leistungsfähiges technisches Prinzip, ersetzt aber weiterhin nicht die Pflege der zugrunde liegenden Definition.

Für betriebliche Daten müssen Identitäten über ihren Lebenszyklus stabil bleiben. Eine Umbenennung darf nicht unbemerkt ein neues Objekt erzeugen. Eine Zusammenführung muss dokumentieren, welche bisherigen Kennungen betroffen sind. Bei versionierten Stammdaten muss erkennbar bleiben, welche Fassung zum Zeitpunkt einer Handlung galt.

Vokabulare, Codelisten und Referenzdaten

Semantische Interoperabilität wird häufig durch kontrollierte Vokabulare, Taxonomien, Codelisten und Referenzdaten vorbereitet. Sie reduzieren frei interpretierbare Bezeichnungen und schaffen vereinbarte Werte.

Eine Codeliste kann beispielsweise zulässige Einheiten, Prüfarten oder Statuswerte festlegen. Ein Vokabular definiert, welche Begriffe für Objekte und Beziehungen verwendet werden. Referenzdaten stellen gemeinsam genutzte Zuordnungen bereit, etwa Marktkennzeichen, Materialklassen oder Organisationseinheiten.

Der European Interoperability Framework nennt Taxonomien, kontrollierte Vokabulare, Thesauri, Codelisten und wiederverwendbare Datenstrukturen ausdrücklich als zentrale Voraussetzungen semantischer Interoperabilität.^[1]

Die bloße Veröffentlichung einer Liste genügt nicht. Jeder Eintrag benötigt eine verständliche Definition, einen Verantwortlichen, einen Geltungsbereich und eine Versionslogik. Ebenso muss geklärt sein, wie Systeme mit veralteten, ersetzten oder lokal erweiterten Werten umgehen.

Ein Code wie REL kann technisch stabil sein. Ohne Definition bleibt jedoch offen, ob er „freigegeben“, „zur Freigabe vorgelegt“ oder „für einen bestimmten Markt freigegeben“ bedeutet. Die Semantik liegt nicht im kurzen Code, sondern in der gemeinsam akzeptierten Beschreibung und seiner Anwendung.

Die Entscheidung braucht Beziehungen zu ihren Bezugsobjekten

Ein Freigabestatus ohne Bezugsobjekt lässt offen, was entschieden wurde. Im Austauschfall sind mindestens die betroffene Charge und die Art der Entscheidung zu unterscheiden. Je nach Zweck kommen Fassung, Zeitpunkt und Einschränkungen hinzu. Ein Datenmodell hält fest, wie diese Informationen zusammengehören.

Knowledge Graphs können solche Beziehungen darstellen; RDF stellt dafür ein Graphdatenmodell bereit.[2] Der technische Zusammenschluss von Graphen klärt aber keine widersprüchliche Verwendung desselben Statusbegriffs. Dafür bleiben die fachlichen Zuordnungen erforderlich.

Formalisierung kann die vereinbarte Unterscheidung ausdrücken

Ontologien können Klassen und Beziehungen formal beschreiben. OWL 2 bietet dafür unter anderem Aussagen über Klassenbeziehungen und Unvereinbarkeit.[3] Das kann helfen, unterschiedliche Entscheidungsarten im Modell ausdrücklich auseinanderzuhalten.

Die Formalisierung ersetzt die Vereinbarung zwischen den Beteiligten nicht. Beide Seiten müssen die gewählte Bedeutung tatsächlich verwenden. Sonst wird ein Konflikt lediglich präziser gespeichert, ohne im Austausch gelöst zu sein.

Gemeinsame Formate reichen nicht aus

CSV, XML, JSON, RDF oder ein standardisiertes Ereignislog können festlegen, wie Daten dargestellt werden. Das allein klärt jedoch nicht, was ein Feld bezeichnet. Der Wert 12 kann eine Menge, eine Dauer, eine Temperatur oder ein Messwert sein. Selbst wenn der Datentyp als Dezimalzahl bekannt ist, bleiben Einheit, Messmethode, Bezugsobjekt und Zeitpunkt offen.

Auch gleiche Feldnamen sind kein sicherer Bedeutungsnachweis. batch kann eine Produktionscharge, eine Materialcharge, einen Importlauf oder eine technische Verarbeitungseinheit meinen. Umgekehrt können lot, charge_id und production_batch in verschiedenen Systemen dasselbe fachliche Konzept bezeichnen.

Vereinbarungen über Format und Bedeutung helfen bei korrekter Umsetzung, Übertragungs- und Interpretationsfehler zu erkennen und zu vermeiden. Sie schließen solche Fehler nicht pauschal aus.

Auch XES und OCEL strukturieren Ereignisdaten auf unterschiedliche Weise. Ob zwei Beteiligte unter einem Ereignistyp, einem Objekttyp oder einem Attribut dasselbe verstehen, muss unabhängig vom gewählten Format fachlich vereinbart werden.

Austauschregeln an gemeinsam vereinbarten Fällen prüfen

Ein gemeinsamer Test sollte einen Produktionsabschluss ohne Qualitätsfreigabe enthalten. Erwartet wird, dass das Zielsystem daraus keine Qualitätsfreigabe ableitet. Ein weiterer Fall übermittelt die passende Entscheidung mit vollständigem Bezug; ein dritter lässt die Entscheidungsart offen und muss entsprechend behandelt werden.

Strukturprüfungen können ergänzend Pflichtangaben kontrollieren. SHACL prüft RDF-Daten gegen formulierte Bedingungen.[4] Ob eine Zuordnung den fachlichen Inhalt erhält, zeigen darüber hinaus die vereinbarten Soll-Ergebnisse der Austauschfälle.

Bei Änderungen an Statusdefinitionen oder Zielmodellen werden gerade diese Fälle erneut relevant. Nur ein technisch erfolgreicher Import würde einen Bedeutungswechsel möglicherweise übersehen.

Vier Ebenen müssen zusammenpassen

Interoperabilität ist mehr als eine funktionierende Schnittstelle. Der European Interoperability Framework von 2017 unterscheidet rechtliche, organisatorische, semantische und technische Interoperabilität. Die folgenden Leitfragen übertragen diese Unterscheidung auf den betrieblichen Datenaustausch.

Die syntaktische Ebene wird im EIF nicht als fünfte oder alternative Hauptebene geführt: Struktur und Format sind dort ein Aspekt der semantischen Interoperabilität. Die rechtliche Ebene ist dagegen ausdrücklich Teil des Modells. Technisch übertragbare und fachlich verständliche Daten dürfen nicht deshalb schon für jeden Zweck genutzt werden.

Die Ebenen bauen nicht wie starre Stufen aufeinander auf. Sie beeinflussen sich gegenseitig. Eine fachliche Definition kann verlangen, dass zusätzliche Felder übertragen werden. Eine organisatorische Änderung kann einen bisherigen Statusbegriff verändern. Eine technische Begrenzung kann dazu führen, dass relevante Beziehungen beim Export verloren gehen.

Governance erhält Bedeutung über die Zeit

Semantik ist kein einmalig abgeschlossenes Datenprojekt. Begriffe verändern sich, Prozesse werden angepasst, Organisationen führen neue Systeme ein und regulatorische Anforderungen entwickeln sich weiter. Deshalb benötigt semantische Interoperabilität dauerhafte Governance.

Zu dieser Governance gehören Verantwortliche für Vokabulare und Referenzdaten, dokumentierte Änderungsverfahren, Versionen, Freigaben und Deprecation-Regeln. Verbraucher müssen erkennen können, welche Version eines Modells ein Datensatz verwendet und wie lange eine ältere Fassung unterstützt wird.

Auch Beispiele und Testdaten sind wichtig. Eine Definition kann sprachlich eindeutig erscheinen und trotzdem unterschiedlich implementiert werden. Gemeinsame Konformitätstests zeigen, ob Sender und Empfänger Grenzfälle tatsächlich gleich behandeln.

Die Verantwortung bleibt fachlich verteilt. Technikteams können Formate und Transformationen umsetzen. Domänenverantwortliche müssen Bedeutung, zulässige Verwendung und Auswirkungen von Änderungen beurteilen. Ohne diese Verbindung entsteht formal saubere, aber betrieblich unzuverlässige Integration.

Was semantische Interoperabilität nicht garantiert

• Gemeinsame Begriffe garantieren keine richtigen Daten. Ein Wert kann semantisch eindeutig und trotzdem falsch erfasst sein.
• Validierung beweist keine reale Wahrheit. Sie prüft Daten gegen formulierte Regeln.
• Interoperabilität ist kein pauschaler Compliance-Nachweis. Rechtliche, regulatorische und organisatorische Anforderungen bleiben gesondert zu prüfen.

Der Empfänger muss dieselbe Entscheidung erkennen können

Im Freigabefall wäre eine unverändert übertragene Zeichenfolge ein schlechtes Ergebnis, wenn das Zielsystem daraus eine andere Berechtigung ableitet. Ein explizit zurückgewiesener unklarer Fall kann dagegen die fachlich richtige Reaktion sein.

Der Maßstab liegt somit im Verhalten des Empfängers: Welches Objekt und welche Aussage erkennt er, welche Verwendung lässt er zu und welche Information fehlt ihm? Definitionen, Mappings und gemeinsame Tests machen diese Fragen überprüfbar.