Knowledge Graphs · Python · Engineering

SHACL mit Python: Engineering Knowledge Graphs gezielt validieren

25. September 2026 · Verfasst von Sara Hofmann

Wie lässt sich prüfen, ob einem technischen Knowledge Graph Quellen oder Nachweise fehlen? Mit SHACL lassen sich ausgewählte Strukturregeln automatisiert testen. Dieser Leitfaden zeigt ein kleines, ausführbares Beispiel mit Turtle und Python: eine technische Entscheidung für ein Review vorbereiten, absichtlich fehlerhafte Daten prüfen und einen grünen Prüfbericht richtig einordnen.

Der Beitrag vertieft die Qualitätsregeln aus dem Einstieg zu Knowledge Graphs in der Bildverarbeitung. Alle Kennungen und Daten sind frei erfundene Lehrbeispiele, keine Kunden- oder Arbeitgeberdaten. Das Ziel ist eine nachvollziehbare Eingangskontrolle, keine automatische technische Freigabe.

Zuerst den Prüfvertrag definieren

Unser Beispiel beantwortet eine eng begrenzte Frage: Ist eine Entscheidung ausreichend verknüpft, um sie einem fachlichen Review zuzuführen? Dafür verlangen wir genau einen Status „ReadyForReview“, mindestens eine Quellenkennung und mindestens eine Nachweiskennung. Diese Auswahl ist ein eigener Modellierungsvorschlag, kein Industriestandard.

Bewusst prüfen wir einen Review-Export, nicht den gesamten Lebenszyklus einer Entscheidung. Entwürfe dürfen im Arbeitssystem unvollständig sein. Werden sie in diesen Export übernommen, sollen sie jedoch scheitern. Wer dieselben Regeln ungefiltert auf einen Gesamtbestand anwendet, erzeugt sonst Fehlermeldungen für fachlich erlaubte Entwurfszustände.

SHACL trennt den Datengraphen von den Regeln im Shapes-Graphen. Targets bestimmen die zu prüfenden Knoten; Bedingungen definieren zulässige Werte. sh:minCount verlangt vorhandene Werte, sh:maxCount begrenzt ihre Zahl und sh:nodeKind sh:IRI verlangt Ressourcenkennungen statt Textliteralen. Maßgeblich ist die W3C-Empfehlung [1].

Eine IRI ist dabei eine Kennung, kein Beleg für einen erfolgreichen Dokumentabruf. Das RDF-Modell unterscheidet Ressourcenkennungen und Literale; eine Zeichenfolge mit einer Adresse ist nicht dasselbe wie die entsprechende IRI. Die Begriffe erläutert RDF 1.1 [2].

Ein vollständiges SHACL-Beispiel mit Python

Die drei folgenden Blöcke als data.ttl, shapes.ttl und validate_graph.py in einem eigenen Arbeitsordner speichern. Benötigt werden Python, RDFLib und pySHACL. Geprüft wurde dieses Beispiel mit Python 3.14, RDFLib 7.6.0 und pySHACL 0.40.1. Für reproduzierbare Versuche diese Versionen in einer separaten Umgebung verwenden; bestehende Projektumgebungen nicht ungeprüft aktualisieren.

1. Datengraph: eine Entscheidung mit Verweisen

@prefix ex: <https://example.org/engineering/> .

ex:decision-17 a ex:Decision ;
    ex:status ex:ReadyForReview ;
    ex:source ex:document-4 ;
    ex:evidence ex:test-9 .

ex: ist ein frei gewähltes Beispielvokabular. Weder das Dokument noch der Test werden hier inhaltlich beschrieben. Diese bewusst kleine Datenbasis hilft, die Grenze zwischen „Verweis vorhanden“ und „Nachweis belastbar“ sichtbar zu machen.

2. Shapes-Graph: der Vertrag für den Review-Export

@prefix ex: <https://example.org/engineering/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:ReviewShape a sh:NodeShape ;
    sh:targetClass ex:Decision ;
    sh:targetSubjectsOf ex:status ;
    sh:class ex:Decision ;
    sh:property [
        sh:path ex:status ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:hasValue ex:ReadyForReview
    ] ;
    sh:property [
        sh:path ex:source ;
        sh:minCount 1 ;
        sh:nodeKind sh:IRI
    ] ;
    sh:property [
        sh:path ex:evidence ;
        sh:minCount 1 ;
        sh:nodeKind sh:IRI
    ] .

Die beiden Targets bilden eine Vereinigung: erfasst werden als ex:Decision klassifizierte Knoten sowie Knoten mit ex:status. Zusammen mit sh:class fällt dadurch auch ein Statusdatensatz ohne passende Klassifizierung auf. sh:hasValue und die Kardinalität verlangen zusammen genau den vorgesehenen Status. Siehe Targets und Constraints [1].

Diese Absicherung hat eine klare Grenze: Fehlen einem Datensatz sowohl Typ als auch Status, greifen unsere Targets nicht. Auch ein leerer Export benötigt deshalb eine separate Vollständigkeitskontrolle gegen die erwarteten Kennungen. Mehr Regeln für Werte lösen keine Lücke in der Auswahl der zu prüfenden Datensätze.

3. Prüfung starten und Ergebnis zurückgeben

from rdflib import Graph
from pyshacl import validate

data = Graph().parse("data.ttl", format="turtle")
shapes = Graph().parse("shapes.ttl", format="turtle")

conforms, report_graph, report_text = validate(
    data,
    shacl_graph=shapes,
    inference="none",
    meta_shacl=True,
    advanced=False,
    allow_infos=False,
    allow_warnings=False,
)
print(report_text)
raise SystemExit(0 if conforms else 1)

Mit python validate_graph.py aus diesem Ordner starten. Der unveränderte Beispieldatensatz soll bestehen. Bei einem Regelverstoß endet das Skript mit Status 1. Es schreibt keine Eingabedateien um. pySHACL liefert Konformität, einen RDF-Ergebnisgraphen und einen lesbaren Bericht; meta_shacl=True prüft zusätzlich den Shapes-Graphen. Die gewählten Optionen sind in der offiziellen Projektdokumentation [3] beschrieben.

inference="none" hält den Versuch ohne zusätzliche RDFS-/OWL-Inferenz. Das ist eine bewusst begrenzte Testkonfiguration. Wird später mit anderen Inferenzoptionen oder einer Ontologie gearbeitet, muss genau diese Konfiguration erneut geprüft werden. Syntax- oder Ausführungsfehler sind ebenfalls fehlgeschlagene Prüfungen, keine Freigabe.

Nicht nur den Erfolgsfall testen

Jede Änderung in der folgenden Liste einzeln auf eine frische Kopie des Beispiels anwenden. So lässt sich ein Ergebnis seiner Ursache zuordnen. Die Gegenproben wurden automatisiert ausgeführt; sie bestätigen das Verhalten dieses Lehrbeispiels, nicht die Qualität eines realen Engineering-Datenbestands.

• Quellenverweis entfernen: muss scheitern. Damit wird geprüft, ob ein fehlender Pflichtwert auffällt.
• Nachweis durch "test-9" ersetzen: muss scheitern. Ein Textliteral erfüllt die geforderte IRI-Bedingung nicht.
• Zweiten Status ergänzen: muss scheitern. Zwei unterschiedliche Werte verletzen die vereinbarte Eindeutigkeit.
• Nur den Typ entfernen, Status behalten: muss scheitern. Das zweite Target verhindert hier einen unbemerkten Ausschluss.
• Typ und Status gemeinsam entfernen: besteht in diesem Beispiel, obwohl noch Verweise vorhanden sind. Das ist die gezielt demonstrierte Abdeckungslücke.
• Eine nicht aufgelöste Nachweis-IRI einsetzen: besteht. Unsere Regeln verlangen eine Kennung, nicht deren Inhalt oder Erreichbarkeit.

Für die Bearbeitung eines Fehlers zuerst den betroffenen Knoten, dann den Eigenschaftspfad und die verletzte Regel betrachten. Diese Angaben sind Bestandteile des SHACL-Ergebnisberichts [1]. Eine fachliche Fehlermeldung sollte zusätzlich erläutern, welches Team welche Daten ergänzen muss. Den Text eines Validators unverändert an alle Beteiligten weiterzuleiten, ist selten eine brauchbare Arbeitsanweisung.

Aus dem Beispiel eine belastbare Eingangskontrolle machen

Für einen praktischen Einsatz empfehle ich vier getrennte Prüfebenen. Diese Aufteilung ist eine technische Arbeitsweise, keine zusätzliche Behauptung des Standards:

1. Abdeckung: Erwartete Entscheidungskennungen aus dem Exportauftrag mit den tatsächlich geprüften Kennungen vergleichen. Fehlende oder leere Lieferungen nicht still akzeptieren.
2. Struktur: Pflichtwerte, erlaubte Zustände und Verknüpfungen prüfen. Für jeden Vertrag mindestens einen gültigen und mehrere gezielt ungültige Testfälle versionieren.
3. Nachweise: Dokumentversion, Zugriff, Anwendbarkeit und Testbedingungen gesondert bewerten. Ein vorhandener Verweis darf nicht automatisch „bestätigt“ bedeuten.
4. Fachliches Review: Eine verantwortliche Person entscheidet, ob die Evidenz die konkrete Aussage trägt. Offene Punkte bleiben explizit offen.

Zum Prüfprotokoll gehören Datenstand, Shapes-Version, Bibliotheksversionen, Optionen und Ergebnis. Bei einer Regeländerung alte und neue Regeln gegen denselben Testbestand ausführen. Sonst bleibt unklar, ob eine veränderte Fehlerzahl aus besseren Daten oder einer schwächeren Prüfung stammt. Regeln und Daten sollten gemeinsam nachvollziehbar sein, aber getrennte Verantwortlichkeiten behalten.

Bei einer Bildverarbeitungsentscheidung könnte der Nachweis später auf einen dokumentierten Vergleich von Segmentierungsverfahren verweisen. Dann muss das Review weiterhin klären, ob Bilder, Beleuchtung und Akzeptanzkriterien zur aktuellen Aufgabe passen. SHACL nimmt diese fachliche Beurteilung nicht ab.

Häufige Fragen

Beweist ein grüner Bericht die Richtigkeit des Knowledge Graphs?

Nein. Er bedeutet nur, dass die tatsächlich ausgewählten Daten die tatsächlich ausgeführten Regeln erfüllen. Unser Beispiel besteht sogar mit einem inhaltlich unbeschriebenen Nachweis. Für die Nutzung einer technischen Aussage sind Abdeckung und Evidenz deshalb eigene Prüfschritte.

Muss ich sofort alle Eigenschaften verbieten, die nicht definiert sind?

Für diesen Einstieg empfehle ich das nicht. Zuerst wenige wichtige Übergaberegeln stabilisieren. Zusätzliche Metadaten wie Bearbeitungsnotizen sollen hier nicht allein deshalb zum Fehler werden, weil sie im kleinen Review-Vertrag nicht vorkommen.

Kann damit ein KI-generierter Graph freigegeben werden?

Nicht allein. Auch plausibel strukturierte Behauptungen können fachlich falsch sein. Ein sinnvoller Ablauf prüft Struktur automatisiert, vergleicht Aussagen mit ihren tatsächlichen Quellen und eskaliert unbelegte Zusammenhänge an das fachliche Review.

Primärquellen

1. W3C: Shapes Constraint Language (SHACL), Recommendation
2. W3C: RDF 1.1 Concepts and Abstract Syntax
3. RDFLib: pySHACL – offizielle Dokumentation und Quellcode

Quellen geprüft am 25. September 2026. Vokabular, Beispieldaten, Gegenproben und Einführungsvorgehen sind eigene Lehr- und Modellierungsvorschläge. Es werden keine betrieblichen Daten oder Projektergebnisse veröffentlicht.