knowmindknowmind
DokumentationQuickstartAnbindungReferenzFehlerbehebung
DEEN

Aufgaben

Beziehungen pflegen

Erinnerungen lassen sich typisiert miteinander verknüpfen. Eine Beziehung trägt einen festen Typ wie REFERENCES_ENTITY, SUPERSEDES oder FOR_CLIENT und macht den Wissensgraph durchsuchbar. Diese Seite zeigt, wie Sie Beziehungen anlegen, prüfen und entfernen.

Zielgruppe
Power-User und Entwicklerinnen und Entwickler, die ihren Wissensspeicher als Graph nutzen wollen. Für reine Such-Anwendungen nicht zwingend nötig — knowmind erzeugt automatisch Referenz-Beziehungen aus Wikilinks im Text.

Voraussetzungen

  • Mindestens zwei vorhandene Erinnerungen mit bekannten Memory-IDs
  • Für MCP- und REST-Wege: API-Token mit Scope write (Tarif Business API oder höher)
  • Übersicht über die zulässigen Edge-Typen — siehe Referenz Beziehungstypen
Hinweis

Inverse-Beziehung wird automatisch angelegt

Jede typisierte Beziehung hat eine festgelegte Inverse-Beziehung (zum Beispiel OWNS ↔ OWNED_BY). knowmind materialisiert die Inverse beim Anlegen automatisch — Sie müssen die Gegenrichtung nicht separat anlegen. Beim Entfernen wird die Inverse-Beziehung mit entfernt.

Schritte

  1. 1

    Weg 1: Implizit beim Speichern (Wikilinks)

    Wenn Sie in einer Erinnerung Tags wie [[ada-lovelace]] oder @projekt-helios verwenden, erzeugt knowmind automatisch REFERENCES_ENTITY-Beziehungen zwischen der Erinnerung und dem genannten Element. Das ist der einfachste Weg und braucht keine manuelle Pflege.

    Ergebnis: Im Wissensgraph erscheint eine Kante zwischen der schreibenden Erinnerung und dem genannten Element. Die Beziehung trägt den Typ REFERENCES_ENTITY mit der Inverse REFERENCED_BY.

  2. 2

    Weg 2: Über den MCP-Client aus der KI heraus

    Aus Claude Code, Claude Desktop oder einem anderen MCP-Client sprechen Sie die KI in natürlicher Sprache an. Die KI ruft knowmind.link auf:

    text
    > Verknüpfe die Erinnerung „Workshop-Memo 12.03." mit der Erinnerung
> „Müller-Vertrag v3" über die Beziehung FOR_CLIENT.

    Die zugehörige Tool-Signatur:

    json
    {
  "name": "knowmind.link",
  "arguments": {
    "from_id": "memory_workshop_2026_03_12",
    "to_id":   "memory_mueller_vertrag_v3",
    "rel_type": "FOR_CLIENT"
  }
}

    Ergebnis: Die KI meldet das Ergebnis. Inverse-Beziehung wird automatisch materialisiert. Beim nächsten Recall mit einer Frage über den Müller-Vertrag wird das Workshop-Memo mitgeliefert.

  3. 3

    Weg 3: Über die REST-API direkt

    Für eigene Backend-Integrationen ohne KI-Vermittlung:

    bash
    # Beziehung anlegen
curl -X POST https://knowmind.de/api/v1/graph/relations/create \
  -H "Authorization: Bearer kmt_…" \
  -H "Content-Type: application/json" \
  -d '{
    "from_id": "memory_workshop_2026_03_12",
    "to_id":   "memory_mueller_vertrag_v3",
    "rel_type": "FOR_CLIENT"
  }'

# Beziehungen einer Erinnerung auflisten
curl -X POST https://knowmind.de/api/v1/graph/relations/list \
  -H "Authorization: Bearer kmt_…" \
  -H "Content-Type: application/json" \
  -d '{ "memory_id": "memory_mueller_vertrag_v3" }'

# Beziehung entfernen
curl -X POST https://knowmind.de/api/v1/graph/relations/delete \
  -H "Authorization: Bearer kmt_…" \
  -H "Content-Type: application/json" \
  -d '{
    "from_id": "memory_workshop_2026_03_12",
    "to_id":   "memory_mueller_vertrag_v3",
    "rel_type": "FOR_CLIENT"
  }'

    Ergebnis: HTTP 200 mit Bestätigung. Wird die Beziehung gegen einen unzulässigen Edge-Typ angelegt, antwortet die API mit HTTP 400 und einer SHACL-Constraint-Meldung mit Domain- und Range-Information.

  4. 4

    Weg 4: Über das Cockpit (in Planung)

    Der grafische Beziehungs-Editor im Cockpit (Liste, Detail-Ansicht mit Drag-and-Drop-Verknüpfung, Inline-Validierung gegen die Edge-Typen) ist in der Backlog vermerkt. Stand 2026-05-23: in Planung, kein fixes Release-Datum.

    Bis dahin verwenden Sie Weg 2 (über die KI im Chat-Stil) oder Weg 3 (REST-API für Skripte und Automatisierungen).

  5. 5

    Beziehung ändern

    Beziehungen sind nicht editierbar — sie werden entfernt und neu angelegt. Soll aus FOR_CLIENT ein SUPERSEDES werden:

    text
    1. knowmind.unlink   from_id=A   to_id=B   rel_type=FOR_CLIENT
2. knowmind.link     from_id=A   to_id=B   rel_type=SUPERSEDES

    Für Fakten-Aktualisierungen (Person zieht um, Vertrag wird verlängert) verwenden Sie nicht knowmind.unlink, sondern knowmind.update_fact — das hält die bi-temporale Historie sauber. Siehe das Konzept bi-temporale Historie.

Prüfung des Ergebnisses

  • knowmind.list_relations mit der Quell-Memory-ID zeigt die neue Beziehung mit Typ und Ziel.
  • Ein Recall mit Kontext-bezogener Frage liefert beide Erinnerungen verknüpft als Treffer.
  • Im NeoDash-Dashboard unter Wissensgraph ist die Kante zwischen den beiden Knoten sichtbar.

Fehlerbehebung

FehlermeldungUrsacheAuflösung
HTTP 400 invalid_edge_typeDer Edge-Typ ist im Schema nicht definiert oder als unzulässige Kombination Domain/Range markiert.Edge-Typ und erlaubte Domain/Range in der Referenz prüfen. Beispiel: FOR_CLIENT erwartet einen Project- oder Document-Knoten als from_id und einen Client-Knoten als to_id.
HTTP 404 memory_not_foundEine der beiden Memory-IDs existiert nicht im aktiven Arbeitsbereich, oder Tippfehler in der ID.Memory-IDs über knowmind.recall oder im Dashboard prüfen und kopieren.
HTTP 403 ForbiddenToken hat keinen write-Scope. Für link und unlink ist write Pflicht.Im Dashboard einen Token mit read und write erstellen oder den vorhandenen Token erweitern.
knowmind.unlink meldet edge_not_found, obwohl die Beziehung sichtbar warEdge-Typ war anders herum angelegt (Inverse). Inverse-Edges werden materialisiert, aber der Original-Typ bleibt richtungsbehaftet.Mit knowmind.list_relations die exakte Edge-Richtung prüfen und unlink mit dieser Richtung aufrufen.

Weiterführend