consolidate relation

consolidate relation prüft einen Beziehungs­namen-Kandidaten gegen das aktuelle Vault-Vokabular und meldet alle existierenden Beziehungs­namen, die ähnlich genug sind, dass eine Konsolidierung lohnt. Lese-Kommando, schreibt nichts. Die Übernahme einer Empfehlung passiert anschließend manuell — typischerweise mit entity link und der kanonischen Schreibweise.

Eine Einordnung in die anderen Ähnlichkeits-Verfahren von Apparat steht in den Grundbegriffen.

Wofür ist das?

• Vor entity link --rel mit einem neuen Beziehungs­namen. Du willst eine Beziehung arbeitet_bei einführen und prüfst, ob es schon works_at (oder eine andere Schreibweise) gibt.
• Vault-Audit. Über die Liste der Beziehungs­namen iterieren und Drift sichtbar machen.

Aufruf

apparat consolidate relation <name> [--vault=<vault>]

Apparat normalisiert das Argument vor dem Vergleich auf snake_case (WorksAt → works_at, arbeitet bei → arbeitet_bei), weil das gespeicherte Vokabular ebenfalls in dieser Form vorliegt. Wenn die Normalisierung das Eingabe­wort verändert, weist Apparat es in der Header-Zeile aus.

Klassen der Ausgabe

Strukturell identisch zu consolidate type: Already canonical / Catalog match / Lexical near matches / Semantic near matches / leeres Ergebnis. Inhaltlich unterscheidet sich das Beziehungs-Pendant an zwei Stellen:

Header zeigt die Normalisierung

Vault "recherche" — consolidation candidates for relation "works_at" (normalised from "WorksAt"):

So siehst du, was Apparat tatsächlich verglichen hat — kein verstecktes Umschreiben.

Themen-Nachbarn sind seltener

Beziehungs­namen wie works_at, knows, references haben in der Praxis keine eigene Definitionsnotiz im Vault. Die Themen-Nachbarschafts-Stufe braucht aber genau eine solche Notiz als Anker. In der Regel trägt deshalb bei consolidate relation die Tippfehler-Stufe die Hauptlast; Themen-Nachbarn melden sich nur, wenn ein Beziehungs­name zufällig auch als Entitäts­titel auftritt.

Beispielausgabe

$ apparat consolidate relation arbeitet_bei --vault=recherche
Vault "Recherche" — consolidation candidates for relation "arbeitet_bei":

Lexical near matches (typos, plural drift, transpositions):
  - "arbeitet_an"  (distance 0.250)

Semantic near matches (relation names with related definition notes):
  - "works_at"     (distance 0.184)

Hier zeigt sich der Wert beider Stufen: Lexikalisch fängt die Schreibvariante arbeitet_an, thematisch das deutsch-englische Synonympaar arbeitet_bei ↔ works_at. Letzteres setzt voraus, dass entweder arbeitet_bei oder works_at als Entitäts­titel im Vault existiert (etwa eine Notiz, in der der Name dokumentiert ist).

Verhalten bei normalisierter Eingabe

$ apparat consolidate relation 'arbeitet bei' --vault=recherche
Vault "Recherche" — consolidation candidates for relation "arbeitet_bei" (normalised from "arbeitet bei"):

Already canonical: "arbeitet_bei" exists verbatim in the vault.

arbeitet_bei ist schon im Vault, entstanden durch frühere entity link-Aufrufe — Apparat erkennt das und meldet die Identität.

Voraussetzungen

• Vault muss existieren und im Mount-Register stehen, oder per --vault direkt adressiert sein.
• Embedding-Dienst läuft im Compose-Stack — sonst fällt die Themen-Nachbarschafts-Stufe still aus, der Rest läuft weiter.

Reservierte Schlüssel

Die reservierten Frontmatter-Schlüssel (id, type, created, updated, language, title, tags, representations, external) erscheinen nicht in den Vorschlägen — sie sind keine Beziehungs­namen, auch wenn ein Operator sie zufällig tippt. Das Kommando warnt nicht aktiv, sondern zeigt schlicht keine Treffer.

Schwellwerte tunen

Im Normalfall reichen die Standard­werte. Wenn du sie ändern willst, gelten dieselben Stell­schrauben wie bei consolidate type.

Exit-Codes

Verwandt

• Ähnlichkeit — Übersicht über alle Verfahren.
• consolidate type — Pendant für Entitäts­typen.
• entity link — der typische nächste Schritt, wenn der Vorschlag eine kanonische Schreibweise nahegelegt hat.