Minimalny standard dla grafu w organizacji: typy encji, relacje, constraints, wersjonowanie i governance.
W skrócie
Schemat musi być egzekwowany (schema gate), nie tylko opisany
Stabilne ID i tombstones chronią cytowalność w czasie
SemVer + ADR to bezpieczne zmiany w ontologii
Provenance jest częścią modelu danych
Dobrze zrobiona ontologia jest mała, ale stabilna. Duża, niestabilna ontologia jest bezużyteczna.
Teza: GraphRAG bez ontologii to „graf tekstów”, który nie daje się utrzymać ani audytować.
Ontologia nie musi być duża — musi być stabilna, wersjonowana i egzekwowana.
1. Po co ontologia
Ontologia (schemat) definiuje, jakie rodzaje encji i relacji wolno publikować oraz jakie właściwości są dopuszczalne.
Dzięki temu:
zmuszamy ekstrakcję do języka domeny, a nie do przypadkowych etykiet,
zapewniamy spójność w czasie (wersje),
ułatwiamy bramki jakości (schema gate),
umożliwiamy stabilne cytowania i provenance.
2. Minimalny model danych
Minimalny schemat (praktyczny) obejmuje:
entity_type: np. Person, Organization, System, Document, Policy, Product.
relation_type: np. owned_by, depends_on, mentions, cites, applies_to.
properties: atrybuty o znanym typie (string/date/url/enum), bez dowolnych pól.
constraints: kardynalność (0..1, 1..N), dozwolone typy końców relacji.
3. Identyfikatory i SSOT
Ontologia musi wymuszać stabilne identyfikatory:
canonical_id — stabilny klucz (nie nazwa),
external_refs — referencje do SSOT (np. numer polityki, identyfikator systemu),
tombstones — rekordy „zastąpione” po merge (redirect do kanonicznego ID).
W praktyce: jeśli nie potrafisz wskazać, który system/produkt/polityka jest „tym samym” obiektem po roku,
nie będziesz w stanie utrzymać grafu w organizacji.
4. Wersjonowanie schematu i migracje
Zalecamy SemVer dla schematu (np. v1.2) i twarde reguły:
MAJOR: zmiana niekompatybilna (np. rename relacji, zmiana typu pola) — wymaga migracji danych.
