In diesem Beitrag
Open Ontologies: Herleitungszertifikate prüfen
Ein zusätzliches Tripel ließ das strukturelle Risiko in unserem Open-Ontologies-Test bei low. Trotzdem entstanden drei neue Konsequenzen. Ein späterer Retrieval-Test endete erfolgreich und meldete zugleich ausdrücklich, dass seine Schlussfolgerung ungeprüft war.
Um ein Herleitungszertifikat von Open Ontologies zu prüfen, bewahrst du den Ausgangsgraphen samt Regelumfang auf. Führe den unabhängigen Prüfer mit den Dateien für Ausgangsaussagen und Herleitungen aus und bewerte das strukturierte Ergebnis zusammen mit dem Prozessstatus. Gib genau den Graphen und die Aussagen frei, deren Prüfung erfolgreich war. Ungeprüfte Ergebnisse und Prüferfehler bleiben offen.
Open Ontologies ist eine quelloffene Engine, die Ontologieänderungen plant und Zertifikate für unterstützte Herleitungen erzeugt. Der Vergleich mit Terraform beschreibt den Ablauf aus Planung, Prüfung und Anwendung einer Änderung. Falls du noch entscheidest, ob dein Agent überhaupt einen Wissensgraphen braucht, beginne mit unserem Entscheidungsleitfaden zu Graph Engineering für KI-Agenten.
Stand von Test und Recherche: . Wir verwendeten per Prüfsumme verifizierte Linux-Dateien aus v2.1.0, veröffentlicht am 23. Oktober 2026. Die Quellverweise zeigen auf den späteren Commit c7fd75f vom 2. November. Eine erfolgreiche unabhängige Prüfung bleibt unbestätigt: Beim unveränderten Zertifikat scheiterte der Prüfer in unserer Umgebung mit einem Laufzeitfehler. Der Testfall untersucht das Verhalten; er liefert keinen Performance-Benchmark.
Was belegt ein Beweis von Open Ontologies?
Ein akzeptiertes Herleitungszertifikat von Open Ontologies belegt, dass seine Schlussfolgerungen unter der unterstützten formalen Semantik aus den gelieferten Ausgangsaussagen folgen. Ob ein Dokument freigegeben, korrekt oder aktuell ist, braucht weiterhin eigene Belege. Ein Prüfer kann die Folgen einer falschen Prämisse bestätigen, ohne ihren Fehler zu erkennen.
Die Dokumentation der Prüfarchitektur trennt zwei Aufgaben: eine Schlussfolgerung prüfen und feststellen, welchen Graphen die Engine verwendet hat.
| Frage | Zu prüfender Beleg | Grenze |
|---|---|---|
| Ist die Herleitung gültig? | Ergebnis des unabhängigen Prüfers für die Dateien mit Ausgangsaussagen und Herleitungen | Gilt unter diesen Ausgangsaussagen und den unterstützten Regeln |
| Ist dies der beabsichtigte Graph? | Graphrevision, Hash der Ausgangsaussagen und ausgewählter Graphumfang | Ein gültiger Beweis kann den falschen Datenstand beschreiben |
| Sind die Ausgangsaussagen verlässlich? | Quellbelege, Prüfung der Extraktion und zuständige Person | Formale Folgerung überprüft keine Tatsachen außerhalb des Systems |
| Darf der Agent das Ergebnis verwenden? | Anwendungsregeln und Zugriffskontrollen | Ein Klassenname erteilt keine Berechtigung |
Unsere Analyse von LLM-as-a-Verifier behandelt erlernte Bewertungen, mit denen du Modellausgaben sortierst. Open Ontologies prüft eine explizite Herleitung anhand von Regeln.
Wie prüfst du ein Herleitungszertifikat von Open Ontologies?
Erzeuge das Zertifikat und führe dann oo-cert mit asserted.tsv und derivations.tsv aus. Bewahre stdout, stderr und den Exit-Code auf. Akzeptieren kannst du das Zertifikat erst, wenn der Prüfer seinen Lauf abschließt und das dokumentierte Erfolgsergebnis zurückgibt.
Der Zertifikatsleitfaden beschreibt einen separaten Lean-Prüfer, der die aufgezeichneten Inferenzschritte erneut prüft. Laut Dokumentation besteht das Erfolgsergebnis aus Exit-Code 0, ok: true und dem Theorem OOCert.certificate_sound. Bei einem abgelehnten Schritt sollen Regel, Schlussfolgerung und Prämissen erkennbar sein.
Lade unseren Open-Ontologies-Testfall mit Zertifikaten und aufgezeichneten Ergebnissen herunter und wechsle in das entpackte Verzeichnis. Das Beispiel setzt voraus, dass die verifizierten Programme für Engine und Prüfer in deinem PATH liegen. Das Paket enthält die Testeingaben und ein Skript zum Erfassen der Ergebnisse; die Programme stellst du separat bereit.
open-ontologies --no-connect --data-dir ./review-store batch - <<'OO'
load proposed.ttl
reason --profile rdfs --certificate ./certificate
OO
oo-cert ./certificate/asserted.tsv ./certificate/derivations.tsvDer Batch lädt den Graphen und führt die Schlussfolgerung im selben Prozess aus. Unser vorgeschlagener Graph enthielt vier Ausgangstripel; die Schlussfolgerung mit rdfs erzeugte drei Herleitungen. Anschließend änderten wir eine Schlussfolgerung: note42 sollte nun zu ApprovedForProduction gehören. Die Prämissen blieben unverändert.
| Eingabe | Beobachtetes Ergebnis | Entscheidung für die Freigabe |
|---|---|---|
| Unverändertes, erzeugtes Zertifikat | Exit-Code 1, leeres stdout, stderr: failed to locate application | Zurückhalten. Der Prüfer gab keine erfolgreiche Verifikation aus |
| Veränderte Schlussfolgerung, unveränderte Prämissen | Exit-Code 1, JSON ok: false, first_rejected: 2, Regel rdfs9 | Veränderte Herleitung ablehnen. Eine konkrete Regelprüfung schlug fehl |
Beide Prozesse endeten mit 1. Nur der zweite lieferte eine strukturierte Regelablehnung. first_rejected: 2 bezeichnet den dritten Herleitungsdatensatz, weil der Index bei null beginnt. Der erste Lauf scheiterte bereits beim Auffinden der Anwendung. Diese Fehler haben unterschiedliche Ursachen; die Negativkontrolle ersetzt keine erfolgreiche Prüfung des ursprünglichen Zertifikats.
Warum braucht auch ein Plan mit niedrigem Risiko eine semantische Prüfung?
Open Ontologies weist strukturelles Risiko und semantische Konsequenzen getrennt aus. Auch ohne neue benannte Klassen können bestehende Regeln neue Klassifizierungen ableiten. Prüfe den Block conservativity und die betroffenen Schlussfolgerungen, bevor du die Änderung als beabsichtigt freigibst.
Unser Ausgangsgraph enthielt diese drei Aussagen. Die Deklaration von Retrievable nimmt diesen Namen bewusst in das ursprüngliche Vokabular auf:
@prefix ex: <https://example.com/knowledge/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
ex:note42 a ex:ProjectNote .
ex:ProjectNote rdfs:subClassOf ex:Document .
ex:Retrievable a rdfs:Class .Der Änderungsvorschlag ergänzt ein Tripel:
ex:Document rdfs:subClassOf ex:Retrievable .Die Dokumentation zur Konservativität grenzt den endlichen Vergleich anhand einer Regeltabelle von einer allgemeinen Garantie logischer Konservativität ab. Unser Plan mit owl-rl meldete eine Einfügung, null betroffene Tripel im Feld für den strukturellen Änderungsradius, risk_score: low und not_conservative_under_rule_table.
| Tripel, verkürzt | Warum es hinzukommt |
|---|---|
| Document ist Unterklasse von Retrievable | Die neue Ausgangsaussage selbst |
| ProjectNote ist Unterklasse von Retrievable | Neue Herleitung über die Unterklassenkette |
| note42 hat den Typ Retrievable | Neue Herleitung anhand dieser Klassifizierung |
Das sind drei neue Konsequenzen, darunter eine Ausgangsaussage und zwei neue Herleitungen. Das Zertifikat enthält drei Herleitungen, weil es zusätzlich note42 type Document aufführt. Diese Klassifizierung folgte bereits aus dem Ausgangsgraphen.
Die veröffentlichte Projektdemonstration nennt 901 neue Konsequenzen in 0,04 Sekunden. Ein separater Versuch umfasst 259 zertifizierte Herleitungen und eine abgelehnte Fälschung. Wir haben diese Anzahlen und Laufzeiten nicht reproduziert. Wie unser Beispiel zeigt, kann die Zahl der Konsequenzen auch die ergänzte Ausgangsaussage einschließen.
Unser Batch-Prozess endete außerdem mit 0, obwohl sein verschachtelter Konservativitätsbericht exit_code: 1 enthielt. Dieser semantische Befund kann eine gewollte Änderung beschreiben. Ein Freigabeprozess muss den Bericht auswerten und die Entscheidung festhalten. Wer nur den Shell-Status prüft, übersieht ihn.
Erhält ein kleinerer RAG-Kontext dieselbe Schlussfolgerung?
Open Ontologies kann prüfen, ob ein ausgewählter Graphenausschnitt bestimmte positive Tripel ohne Variablen unter einem gewählten Regelprofil weiterhin stützt. Du gibst die zu prüfenden Aussagen vor. Das Werkzeug extrahiert und validiert nicht jede Aussage einer generierten Antwort. Auch ein hoher Anteil erhaltener Nachbartripel belegt nicht, dass die benötigten Prämissen erhalten geblieben sind.
In unserem Testfall lautet das Ziel note42 type Retrievable. Der vollständige Ausschnitt enthält die drei Tripel dieser Herleitung und lässt die eigenständige Klassendeklaration weg. Im gekürzten Ausschnitt fehlt ProjectNote subClassOf Document. Beide bleiben Teilmengen des vorgeschlagenen Graphen.
Der Leitfaden zur Folgerung aus Graphenausschnitten vergibt unterschiedliche Namen für geprüfte, direkt vorliegende und ungeprüfte Ergebnisse:
| Lauf | Ergebnis für das Ziel | Prozessstatus | Bedeutung für die Freigabe |
|---|---|---|---|
| Vollständiger Ausschnitt, kein Prüfer konfiguriert | preserved_unchecked | 0 | Die Engine leitet das Ziel ab; die unabhängige Prüfung fehlt |
| Gekürzter Ausschnitt, kein Prüfer konfiguriert | lost_under_profile_unchecked | 1 | Das gewählte Profil leitet das Ziel aus diesem Ausschnitt nicht mehr ab |
| Vollständiger Ausschnitt, Prüfer vorgeschrieben | certificate_rejected, STOP_THE_LINE | 2 | Zurückhalten und die ursprüngliche Fehlermeldung des Prüfers untersuchen |
In der dritten Zeile enthält der Bericht denselben Laufzeitfehler failed to locate application. Die Ablehnungsbezeichnung des Wrappers belegt deshalb nicht, dass die Herleitung an einer Regelprüfung gescheitert ist. In dieser Umgebung haben wir kein preserved_checked erhalten.
Auch der Befund über den Verlust einer Folgerung hat Grenzen: Er beschreibt das negative Engine-Ergebnis innerhalb der unterstützten Regeln. Er beweist keine Nichtfolgerung in jeder Ontologielogik. Verlangt ein Workflow einen Beweis, würden wir ein ungeprüftes positives Ergebnis zurückhalten, eine fehlende Prämisse wiederherstellen und einen Prüferfehler untersuchen, bevor der Agent die Aussage verwenden darf.
Das Erhalten einer Folgerung klärt keine Zugriffsrechte. Unser Leitfaden zu RAG-Berechtigungen behandelt die vorgelagerte Frage, ob der Nutzer diese Fakten überhaupt abrufen darf.
Was gehört in das Freigabeprotokoll?
Ein Freigabeprotokoll für Open Ontologies sollte Graphrevision, ausgewählte Ausgangsaussagen, Regelprofil, semantische Änderung und das genaue Prüfergebnis festhalten. Bei einem abgerufenen Ausschnitt kommen die Einzelurteile zu den Zielen hinzu. Das ist unser Vorschlag für die Anwendungsregeln. Er bedeutet nicht, dass die Engine betriebliche Änderungen automatisch freigibt.
| Aufzeichnung | Frage für die Freigabe |
|---|---|
| Identität von Engine und Prüfer | Welche heruntergeladenen Programme oder Builds liefen, und stimmen ihre Hashes mit den geprüften Versionen überein? |
| Graphrevision und Bytes der Ausgangsaussagen | Beschreibt das Zertifikat genau die Eingabe, die für diesen Lauf freigegeben wurde? |
| Ausgewählter Umfang und Profil | Welche Graphen und Regeln wurden verwendet, und wurden relevante Konstrukte oder Ziele zurückgewiesen? |
| Bericht zur semantischen Änderung | Hat eine zuständige Person die gemeldeten Konsequenzen akzeptiert und offene Befunde geklärt, unabhängig vom strukturellen Risikolabel? |
| stdout, stderr und Exit-Code des Prüfers | Hat der vorgesehene Prüfer eine erfolgreiche Verifikation ausgegeben? |
| Ausschnitt, explizite Ziele und Einzelurteile | Liegen für jede erforderliche abgeleitete Aussage die Belege vor, die deine Anwendung verlangt? |
Die Dokumentation zur vertrauenswürdigen Rechenbasis erklärt, dass der Prüfer Zertifikatsdateien liest. Deinen beabsichtigten Anwendungszustand kennt er nicht. Er untersucht auch scope.tsv nicht; der Aufrufer muss diese Auswahl prüfen. Ein Hash bindet die Bytes der Ausgangsaussagen. Er belegt weder ihre Wahrheit und Aktualität noch ihren Berechtigungsstatus.
Für diesen Versuch bleibt die Entscheidung bis zur unabhängigen Verifikation zurückhalten. Die Ablehnung der Fälschung ist ein nützlicher Befund. Sie ersetzt jedoch keine erfolgreiche Prüfung des Zertifikats, das du verwenden willst. Wiederhole die Kontrollen für erfolgreiche Prüfung und Ablehnung auf deinem Deployment-Host, bevor du sie mit einem Agenten verbindest.
Wie verbindest du Open Ontologies mit Claude Code?
Registriere Open Ontologies als lokalen stdio-MCP-Server mit einem expliziten Programm- und Speicherpfad. Entscheide bewusst über die Persistenz: Standardmäßig liegt der Speicher im Arbeitsspeicher. Ein Prozessneustart erhält den geladenen Graphen daher nicht. Eine funktionierende MCP-Verbindung belegt auch nicht, dass der separate Beweisprüfer installiert ist.
Die auf den Commit festgelegte Speicher- und Embedding-Konfiguration definiert den Standard im Arbeitsspeicher sowie den persistenten Modus. Nach der aktuellen MCP-Anleitung für Claude Code nutzt diese Registrierung den lokalen Transport:
claude mcp add \
--env OPEN_ONTOLOGIES_STORAGE_MODE=persistent \
--transport stdio open-ontologies -- \
/absolute/path/open-ontologies \
--data-dir /absolute/path/oo-store serveErsetze beide absoluten Pfade. Konfiguriere und verifiziere den Prüfer separat und kontrolliere die Verbindung anschließend mit /mcp. Wir haben die Befehlsstruktur mit der Dokumentation abgeglichen. Eine laufende Claude-Code-Sitzung oder jeden MCP-Client haben wir nicht getestet. --data-dir ist hier ein CLI-Flag, keine Umgebungsvariable.
Plane Zeit für beide Programme und eine erfolgreiche Beweisprüfung auf deinem Deployment-Host ein. Unser Test belegt keine verifizierte Einrichtung in einer Minute.
Wann würden wir Open Ontologies einsetzen?
Wir würden Open Ontologies prüfen, wenn ein Agent von expliziten, nachvollziehbaren Aussagen und Regeln abhängt, deren Konsequenzen relevant sind. Beginne mit einer wichtigen Aussage, einer vorgeschlagenen Ontologieänderung und einer absichtlich beschädigten Herleitung. Erweitere den Umfang erst, wenn die Deployment-Umgebung sowohl die erfolgreiche unabhängige Prüfung als auch die erwartete Ablehnung nachweist.
Wenn du diese Schlussfolgerungsschicht mit einer Anwendung verbinden willst, ist unsere Entwicklung von KI-Produkten und Agenten der passende nächste Schritt. Definiere die Aussagen und Freigabekriterien, bevor du den Graphen erweiterst.
Fragen zur Beweisprüfung mit Open Ontologies
Ist Open Ontologies ein Terraform-Provider?
Der Terraform-Vergleich des Projekts beschreibt das Planen, Prüfen, Anwenden und Zurückrollen von Ontologieänderungen. Er belegt keine Kompatibilität mit Terraform-Providern oder HCL. Behandle Open Ontologies als eigenständiges Werkzeug für Schlussfolgerungen und Änderungen. Prüfe seine tatsächlichen Befehle und Belegformate, bevor du anhand dieser Analogie eine Integration entwirfst.
Verhindert Open Ontologies jede Halluzination eines Agenten?
Nein. Ein Herleitungsprüfer deckt festgelegte formale Schlussfolgerungen aus gelieferten Ausgangsaussagen unter unterstützten Regeln ab. Ein Agent kann weiterhin eine falsche Aussage extrahieren, ein nötiges Ziel auslassen, ein Ergebnis falsch beschreiben oder etwas Ungeprüftes behaupten. Die Anwendung muss die geprüften Tripel mit ihren freigegebenen Aussagen verbinden und die Quellbelege der Ausgangsaussagen erhalten.
Kann dasselbe Herleitungszertifikat auch OWL-DL-Schlussfolgerungen zertifizieren?
Der dokumentierte Pfad reason --certificate unterstützt rdfs, owl-rl und owl-rl-ext; owl-dl weist dieses Flag zurück. Das Projekt bietet weitere Prüfmechanismen, die du separat bewerten musst. Eine erfolgreiche Prüfung innerhalb eines unterstützten Regelfragments rechtfertigt keine Aussage darüber, dass jedes OWL-Konstrukt oder jede Engine-Antwort zertifiziert sei.
Beweist ein Zertifikat, dass eigene Horn-Regeln korrekt sind?
Ein Horn-Zertifikat mit übergebenen Regeln beweist eine Schlussfolgerung relativ zu diesen Regeln und den Ausgangsaussagen. Die Regeln bleiben Annahmen. Bewahre Urteile wie entailed_under_supplied_rules vollständig auf und prüfe die Regeltabelle samt Hash. Verkürzt du das Ergebnis auf ein allgemeines „bewiesen“, verbirgst du eine Annahme, die bei der Prüfung sichtbar bleiben muss.
Bleiben bei lokaler MCP-Ausführung alle Daten auf meinem Gerät?
Lokale Schlussfolgerung allein belegt keinen vollständig lokalen KI-Workflow. Werkzeugergebnisse gehen an den MCP-Client zurück, dessen Modell auf einem entfernten Server laufen kann. Die untersuchte Konfiguration unterstützt außerdem eine OpenAI-kompatible Embedding-API. Der Schnellstart des Projekts dokumentiert Modelldownloads für die Embedding-Initialisierung. Prüfe den gewählten Build, den Anbieter und den Datenfluss des Clients, bevor du einen rein lokalen Betrieb zusicherst.
Erklärt derivations.tsv jede mögliche Begründung?
Nein. Laut Zertifikatsleitfaden wird pro neu abgeleitetem Tripel ein Herleitungsschritt aufgezeichnet: der zuerst gefundene. Eine Schlussfolgerung kann weitere gültige Begründungen haben, die diese Datei nicht aufzählt. Nutze dafür die gesonderten Mechanismen des Projekts für Begründungen und Provenienz. Bewerte deren Garantien unabhängig davon, ob dieses einzelne Zertifikat erfolgreich geprüft wird.