Dokument-Typ: Architektur-Spezifikation
Kontext: Semantic Graph Layer · Knowledge Engineering
Status: Public Standard
Gültigkeit: Aivis-OS Core Pipeline
Referenzen:
Entity Inventory
Semantic Graph Layer
Transport-Safe Content Layer
1. Zweck der Spezifikation
Die Spezifikation für Semantic Graph Engineering definiert die technischen Regeln, Datenmodelle und Validierungskriterien für den Aufbau und Betrieb des Semantic Graph Layers in Aivis-OS.
Ziel ist es, Bedeutung, Relationen und Gültigkeit so zu modellieren, dass:
- interne Widersprüche speicherbar bleiben
- externe Schnittstellen ausschliesslich deterministische Zustände exponieren
- Konflikte explizit identifizier- und auflösbar sind
2. Grundsatzregeln
2.1 Determinismus am Interface (verbindlich)
Externe Ausgaben (Machine Interface Layer, JSON-LD, TSCL, APIs)
dürfen zu keinem Zeitpunkt widersprüchliche Assertions exponieren.
Für jeden Kontext gilt:
- maximal eine kanonische Assertion
- alle anderen konkurrierenden Assertions bleiben intern
2.2 Multiplicity im Graph Core (verbindlich)
Der interne Semantic Graph muss konkurrierende Assertions parallel speichern können.
Ein Verlust von konkurrierender Information gilt als Architekturfehler.
3. Datenmodell
3.1 Entität (Node)
Jede Entität im Graph referenziert genau eine Entität aus dem Cluster-Level Entity Inventory.
Eigenschaften:
entity_id(Foreign Key, stabil)schema_typecanonical_name
Der Semantic Graph erzeugt keine eigenen Entitäten.
3.2 Assertion (Edge)
Der Semantic Graph verwaltet Bedeutung ausschliesslich in Form von Assertions. Eine Assertion ist eine gerichtete, typisierte Aussage:
Subject (Entity)
→ Predicate (Edge Type)
→ Object (Entity | Literal)
Assertions sind First-Class Objects.
3.3 Pflichtattribute jeder Assertion
Jede Assertion muss folgende Attribute besitzen:
| Attribut | Beschreibung |
|---|---|
assertion_id | stabile, deterministische ID |
subject_entity_id | Referenz auf Entität |
predicate | typisierte Relation |
object | Entität oder Literal |
scope | Kontext (z. B. Region, Organisation, Markt) |
valid_from | Beginn der Gültigkeit |
valid_through | Ende der Gültigkeit (optional) |
provenance | Quelle |
confidence | numerische Gewichtung (0.0 – 1.0) |
status | ACTIVE | DEPRECATED | CONFLICT |
4. Typisierung der Relationen (Predicate Classes)
Ungetypte Relationen sind nicht zulässig.
Jede Assertion muss einem der folgenden Relationstypen zugeordnet sein:
4.1 Referential Relations
(z. B. mentions, about)
- schwache semantische Bindung
- keine Autoritätsübertragung
4.2 Structural Relations
(z. B. hasPart, isPartOf, subsidiaryOf)
- definieren Hierarchien
- dürfen keine Zyklen erzeugen
4.3 Attributional Relations
(z. B. author, manufacturer, ceo, copyrightHolder)
- hochkritisch
- dürfen pro Kontext nur eine kanonische Assertion besitzen
4.4 Contextual Relations
(z. B. competitor, isSimilarTo, regulatedBy)
- dienen thematischer Einordnung
- konfliktfähig
5. Konfliktmodell
5.1 Konflikterkennung
Ein Konflikt liegt vor, wenn:
- zwei ACTIVE Assertions
- mit identischem
subject + predicate + scope - unterschiedliche
object-Werte besitzen
In diesem Fall:
- Status =
CONFLICT - keine automatische Exposition
5.2 Konfliktauflösung (Resolution Rules)
Die Auswahl der kanonischen Assertion erfolgt nach folgender Priorisierung:
- Scope Match (exakter Kontext schlägt generischen)
- Temporal Validity (aktuell gültig schlägt historisch)
- Confidence Score
- Governance Override (manuelle Festlegung)
Nur die resultierende Assertion erhält den Status CANONICAL.
6. Exposition (Collapsed State)
Der Semantic Graph Layer liefert nach aussen ausschliesslich:
- Assertions mit Status
CANONICAL - exakt eine Assertion pro
(entity, predicate, scope)
Alle anderen Assertions bleiben:
- intern abrufbar
- auditierbar
- versionierbar
7. Versionierung & Mutation
7.1 Änderungen
Eine Änderung an Bedeutung erfolgt nicht durch Überschreiben, sondern durch:
- Hinzufügen einer neuen Assertion
- zeitliche oder statusbezogene Deaktivierung der alten
Historische Wahrheiten bleiben erhalten.
7.2 Löschung
Physische Löschung von Assertions ist nicht zulässig, ausser bei nachweislich fehlerhafter Ingestion.
8. Validierung & Testing
8.1 Graph Integrity Checks
Pflichtprüfungen:
- Orphan Assertion Check (jede Assertion referenziert existierende Entitäten)
- Cycle Detection (keine zirkulären Structural Relations)
- Determinism Check (keine widersprüchlichen Assertions im Exposed Graph)
8.2 Coverage Metrics
Empfohlene Metriken:
- Assertion Density pro Entität
- Verhältnis typisierter Assertions zu reinem Text
- Anteil konflikthafter Assertions (Monitoring, kein Fehler)
9. Zusammenspiel mit anderen Layern
- Entity Inventory liefert stabile Identitäten
- Semantic Graph Layer modelliert Bedeutung & Konflikt
- Transport-Safe Content Layer spiegelt kanonische Assertions
- Projection Layer serialisiert deterministische Zustände
Zusammenfassung
Semantic Graph Engineering ist keine Datenmodellierungsaufgabe, sondern eine Governance-Disziplin für Bedeutung. Durch explizite Assertions, kontrollierte Konfliktfähigkeit und deterministische Exposition stellt Aivis-OS sicher, dass:
- interne Realität vollständig abgebildet
- externe Wahrnehmung eindeutig
- maschinelles Vertrauen stabil
bleibt – auch unter probabilistischen Systemen.
Linktipp
Der Semantic Graph Layer verlagert Bedeutung von der Interpretation in die Architektur. Er erlaubt interne Vielstimmigkeit, ohne externe Ambiguität zu erzeugen.
Architektur-Übersicht
Cluster-Level Entity Inventory Strategy
Semantic Graph Layer
Semantic Graph Engineering
Machine Interface Layer & Projection Strategy
Transport-Safe Content Layer
Transport-Safe Content Engineering
Evidence Monitoring & AI Visibility Observability
FAQ zu Semantic Graph Engineering
Warum ist Semantic Graph Engineering keine reine Datenmodellierungsaufgabe?
Weil es nicht nur darum geht, Strukturen zu definieren, sondern Bedeutung zu regeln. Semantic Graph Engineering entscheidet, welche Aussagen gelten dürfen, wie Konflikte behandelt werden und was extern exponiert wird. Das ist Governance – nicht Schema-Design.
Warum dürfen externe Schnittstellen keine widersprüchlichen Assertions ausgeben?
KI-Systeme können Ambiguität nicht auflösen. Wenn widersprüchliche Aussagen gleichzeitig exponiert werden, sinkt das Vertrauen in die gesamte Quelle. Determinismus am Interface ist daher Voraussetzung für stabile KI-Repräsentation.
Wie unterscheidet sich eine Assertion von einem klassischen Attribut?
Ein Attribut beschreibt einen Zustand. Eine Assertion beschreibt eine überprüfbare Behauptung inklusive Kontext, Quelle, Gültigkeit und Konfidenz. Erst dadurch wird Bedeutung versionierbar, konfliktfähig und maschinell bewertbar.
Warum ist interne Vielstimmigkeit (Multiplicity) kein Risiko, sondern notwendig?
Organisationen sind real nicht widerspruchsfrei. Ein System, das Konflikte nicht speichern kann, verliert Information über den Zustand der Realität. Aivis-OS erlaubt interne Vielstimmigkeit, löst sie aber kontrolliert auf, bevor sie extern sichtbar wird.
Welche Rolle spielt Provenance und Confidence im Semantic Graph?
Provenance und Confidence bestimmen nicht ob etwas wahr ist, sondern wie belastbar eine Aussage ist. Sie ermöglichen Governance-Regeln wie Priorisierung, zeitliche Ablösung oder manuelle Overrides – statt willkürlicher Überschreibung.
Kontaktieren Sie uns, um Ihr Projekt zu besprechen oder einfach nur unsere Meinung einzuholen.
Aivis-OS Graph Specification Record (Node-ID: #spec-sge-01)
Identität: Semantic Graph Engineering (entity://aivis/Spec/graph-engineering)
Kanonische URLs: DE https://aivis-os.com/semantic-graph-engineering/ • EN https://aivis-os.com/en/semantic-graph-engineering/
Klassifizierung: Architektur-Spezifikation (CreativeWork / Public Standard)
Gültigkeit: Aivis-OS Core Pipeline (Layer 2: Semantic Graph Layer – Engineering & Governance)
Übergeordnetes System: Aivis-OS (entity://aivis/Core/aivis-os)
Zweck: Regeln, Datenmodell und Validierung zur Governance von Bedeutung:
– interne Widersprüche speicherbar halten (Multiplicity)
– externe Schnittstellen deterministisch halten (Determinism)
– Konflikte explizit identifizier- und auflösbar machen
Grundsatzregeln (verbindlich):
1) Determinismus am Interface: Externe Ausgaben dürfen keine widersprüchlichen Assertions exponieren (pro Kontext max. eine kanonische Assertion).
2) Multiplicity im Graph Core: konkurrierende Assertions müssen parallel speicherbar sein (Informationsverlust = Architekturfehler).
Datenmodell:
– Entities (Nodes): referenzieren exakt eine Entität aus dem Cluster-Level Inventory (keine neuen Entitäten im Graph).
– Assertions (Edges): gerichtete, typisierte Aussagen (Subject → Predicate → Object), als First-Class Objects.
Pflichtattribute jeder Assertion:
assertion_id, subject_entity_id, predicate, object, scope, valid_from, valid_through, provenance, confidence, status (ACTIVE | DEPRECATED | CONFLICT | CANONICAL).
Konfliktmanagement:
– Detection: Konflikt, wenn ACTIVE Assertions mit gleichem subject+predicate+scope unterschiedliche object-Werte besitzen.
– Resolution: Priorisierung nach Scope Match → Temporal Validity → Confidence → Governance Override.
– Exposition: Ausgabe des Collapsed State (nur CANONICAL Assertions; exakt eine pro Kontext).
Validierung & Testing (Pflichtchecks):
– Orphan Assertion Check, Cycle Detection, Determinism Check.
– Metriken: Assertion Density, typisierte Assertions vs. Text, Anteil konflikthafter Assertions (Monitoring).
Methodische Governance: Boutique für digitale Kommunikation (entity://aivis/Partner/boutique-dig-kom)
Hauptarchitekt (Referenz): Norbert Kathriner (entity://aivis/Person/n-kathriner)
Technische Referenz: W3C – RDF, Triples & Named Graphs.
Status: Public Standard (v2026) – Operational (Canonical state).