Halconia.
Kontakt
Zurück zum Blog

Was sind Wissensgraphen in der Fertigung?

In diesem Artikel verwenden wir Wissensgraph in der Fertigung als Arbeitsdefinition für eine Darstellung von Entitäten und Beziehungen…

Andrés Naves ·

In diesem Artikel verwenden wir Wissensgraph in der Fertigung als Arbeitsdefinition für eine Darstellung von Entitäten und Beziehungen, deren Bedeutung durch Vokabulare dokumentiert wird; wir erläutern sie anhand von RDF, einem Datenmodell, das es ermöglicht, Aussagen über Ressourcen zu formulieren und diese mit Vokabularen oder Konventionen zu kombinieren, die semantische Informationen liefern (RDF Primer).

In unserem hypothetischen Beispiel sind die Maschine M und die Komponente C physische Ressourcen, und ein Dokument mit zwei Revisionen, D1 und D2, liefert die dokumentarischen Ressourcen, die wir mittels RDF-Tripeln miteinander verknüpfen.

Die Grundlage bildet unser vorheriger Artikel: Warum operatives Wissen in Systeme der industriellen Automatisierung integrieren

Was ist ein Wissensgraph in der Fertigung und wie stellt er Maschinen, Komponenten und Dokumente dar?

RDF-Tripel haben drei Elemente: Subjekt, Prädikat und Objekt. Das Subjekt und das Objekt repräsentieren die beiden verknüpften Ressourcen, während das Prädikat die Art ihrer Beziehung ausdrückt (RDF Primer).

Unser erstes hypothetisches Tripel lautet Maschine M — enthält — Komponente C: Die Maschine ist das Subjekt, enthält ist das Prädikat und die Komponente ist das Objekt.

Das zweite hypothetische Tripel lautet Komponente C — hat Dokumentation — Revision D2: Die Komponente ist das Subjekt, hat Dokumentation ist das Prädikat und die aktuelle Revision des Beispiels, D2, ist das Objekt. In diesem RDF-Modell haben wir enthält und hat Dokumentation als lokale Konventionen des Beispiels gewählt, nicht als normalisierte Industriebegriffe.

Wenn wir diese Tripel als Graph visualisieren, bilden ihre Subjekte und Objekte die Knoten und ihre Prädikate die Kanten: Die gemeinsame Komponente verbindet die Maschine mit der dokumentarischen Revision.

Wie vereinbaren wir Kennungen und Vokabular, ohne eine Entität mit ihren verschiedenen Revisionen zu verwechseln?

IRIs sind globale Identifikatoren für Ressourcen (RDF Primer). Der Eigentümer einer IRI kann dokumentieren, welche Ressource damit bezeichnet werden soll; in unserem hypothetischen Beispiel würde diese Spezifikation die Maschine, die Komponente, das persistente Dokument und jede dokumentarische Revision anhand ihrer jeweiligen Identifikatoren unterscheiden (RDF Concepts).

In Anlehnung an die Unterscheidung, die PROV-O veranschaulicht, hat in unserem Modell jede Revision ihren eigenen Identifikator, und beide sind konkrete Formen eines persistenten Dokuments mit einer gemeinsamen Referenz (PROV-O).

PROV-O definiert eine Revision als eine Ableitung, deren Ergebnis eine überarbeitete Version einer ursprünglichen Entität ist. Wir wenden diese Definition über prov:wasRevisionOf an: Die aktuelle Revision ist das Subjekt dieser Beziehung und die vorherige Revision ihr Objekt (PROV-O).

Die Eigenschaft prov:specializationOf verknüpft eine spezifischere Entität mit einer anderen, deren Aspekte sie vollständig teilt. Wir wenden sie auf jede Revision in Bezug auf das persistente Dokument an, wenn beide Versionen als spezifischere Formen desselben Dokuments modelliert werden, in Anlehnung an die Unterscheidung, die PROV-O veranschaulicht.

Das W3C empfiehlt, Identifikatoren sowohl für Versionen als auch für die gesamte Reihe eines Datensatzes zu vergeben; in unserem Beispiel wenden wir diese Trennung auf das Dokument als Modellierungsentscheidung an (Data on the Web Best Practices).

Bevor wir Identifikatoren erstellen, schlagen wir vor, zunächst nach geeigneten bereits existierenden zu suchen; falls wir neue erstellen müssen, folgen wir den vom W3C empfohlenen Mustern zur URI-Persistenz (Data on the Web Best Practices).

Laut W3C ist es ratsam, für die Kodierung von Daten und Metadaten Begriffe aus gemeinsam genutzten, vorzugsweise standardisierten Vokabularen wiederzuverwenden.

Wie halten wir fest, woher eine Aussage stammt, ohne ihre Herkunft in eine Garantie der Wahrheit oder eine Nutzungsgenehmigung umzudeuten?

PROV-O ermöglicht den Aufbau von Provenienzketten mit Entitäten und Aktivitäten: Eine Aktivität kann bestimmte Entitäten verwenden und andere erzeugen. In unserem Beispiel verwendet eine Abfrageaktivität die aktuelle Revision und erzeugt einen Datensatz, der die dokumentarische Aussage über die Komponente enthält (PROV-O).

Die Aktivität wird über prov:used mit der Revision verknüpft, während der Datensatz über prov:wasGeneratedBy mit der Aktivität verknüpft wird, die ihn erzeugt hat. In unserem Beispiel würde prov:wasDerivedFrom den Datensatz mit der dokumentarischen Revision verknüpfen, von der er abgeleitet ist; PROV-O definiert Ableitung als die Umwandlung einer Entität in eine andere (PROV-O). Zur Angabe der Verantwortlichkeit verbindet prov:wasAssociatedWith die Aktivität mit einem Agenten, und prov:wasAttributedTo schreibt die erzeugte Entität einem Agenten zu.

In unserem Modell beschreiben diese Eigenschaften die Erzeugung und Zuschreibung des Datensatzes als Entität; wir haben die Provenienz jedes Tripels nicht separat modelliert. Es genügt auch nicht, einen Graphen zu benennen: RDF legt keine formalen Einschränkungen für die Ressource fest, die dieser Name bezeichnet, noch für ihre Beziehung zum Graphen (RDF Concepts).

Damit Leser den Namen eines Graphen als Quelle seiner Daten interpretieren können, brauchen sie eine zusätzliche Konvention, da RDF keine standardisierte Möglichkeit bietet, diese semantische Annahme zu übermitteln (RDF Primer).

Der Verweis auf die Primärquellen ermöglicht es, die Verlässlichkeit einer abgeleiteten Quelle zu untersuchen, laut PROV-O. Außerdem gehen die logischen Inferenzen von RDF von Tripeln aus, die das System als wahr akzeptiert: Eine abgeleitete Schlussfolgerung behält diese Abhängigkeit von den Eingabeinformationen bei.

Um die Nutzungsberechtigung in unserem Pilotprojekt zu prüfen, werden wir zusätzlich zur Erfassung der Zuordnung die anwendbare Lizenz konsultieren. Das W3C empfiehlt, einen Link oder eine Kopie der Lizenzvereinbarung bereitzustellen, die die Nutzung der Daten regelt. In diesem Beispiel prüfen wir die Lizenz, die Zugriffsregeln und die technische Freigabe eines Eingriffs getrennt. In unserem Modell definieren wir das dokumentarische Prädikat ausschließlich, um die Komponente mit einer Revision zu verknüpfen; die Gültigkeit, Anwendbarkeit und Freigabe dieser Revision liegen außerhalb der Bedeutung, die wir ihm zugewiesen haben.

Wie grenzen wir einen Pilotversuch ab und was prüfen wir, bevor wir ihn ausweiten?

In diesem hypothetischen Pilotprojekt überprüfen wir die Darstellung der Beziehungen und die semantische Kohärenz der Tripel.

Eine erste Abfrage würde die Tripel durchlaufen, die die Maschine mit der Komponente und diese mit der dokumentarischen Revision verknüpfen, indem sie deren Subjekte, Prädikate und Objekte verfolgt. Eine andere würde den Provenienzbeziehungen vom Datensatz bis zur Aktivität folgen, die ihn erzeugt hat, und zur Entität, die diese Aktivität verwendet hat.

Zur Überprüfung der Versionen würden wir die Beziehung prov:wasRevisionOf zwischen der aktuellen und der vorherigen Revision lesen und dabei ihre Identifikatoren getrennt von dem des persistenten Dokuments halten. Die gemeinsame Lesart dieser Beziehungen muss eine vereinbarte Bedeutung bewahren: Der RDF Primer erklärt, dass das Zusammenführen von Informationen mit einer gemeinsamen Syntax nicht ausreicht, um ihre semantische Kohärenz zu gewährleisten.

Von diesem hypothetischen Pilotprojekt ausgeschlossen sind die physische Überprüfung der installierten Komponente, die Anwendbarkeit einer Revision auf einen Eingriff und die Nutzungsbedingungen; wir schlagen vor, diese getrennt durch eine technische Prüfung und eine Prüfung der anwendbaren Lizenz zu behandeln.

Prüfungen des hypothetischen Pilotversuchs

  • Prüfen, ob Verweise auf dieselbe Entität in den verbundenen Datensätzen dieselbe Kennung verwenden.
  • Die vereinbarte Bedeutung der Tripel prüfen, nicht nur ihre Syntax.
  • Prüfen, ob die Historie die Änderungen zwischen den Versionen erklärt.
  • Prüfen, ob eine Anwendung die Herkunftsinformationen verarbeiten kann.
  • Prüfen, ob die Lizenz bereitgestellt wird, die die Nutzung der Daten regelt.
  • Die bekannte Qualität und die festgestellten Probleme in den Metadaten dokumentieren.

Quellen