Notezbeta
Zurück zum Blog

Links, die eine Umbenennung überstehen

ProductivityDenis Povarov

Wer ein verlinktes Archiv länger als ein Jahr führt, kennt diesen Fehler.

Du hast eine Notiz namens Q3 planning angelegt. In acht Monaten kamen dreißig Notizen dazu, die auf sie verweisen. Dann war Q3 vorbei, und du hast sie in Q3 planning (2025) umbenannt, was offensichtlich richtig war.

Dreißig Links waren kaputt, still und leise. Sie werden weiter angezeigt, sehen weiter wie Links aus und zeigen jetzt auf eine Notiz, die es nicht gibt. Manche Systeme bieten hilfsbereit an, sie für dich anzulegen, und so geistert eine zweite, leere Notiz Q3 planning durch deinen Graphen.

Die Ursache: Die meisten Notizen-Apps im Wiki-Stil speichern den Link als Titel. [[Q3 planning]] ist buchstäblich die Zeichenkette „Q3 planning“, und beim Anzeigen sucht die App eine Notiz mit diesem Namen. Der Link ist eine Vermutung, die meistens zufällig stimmt.

Notez speichert die ID.

Was [[ tatsächlich einfügt

Tippst du im Editor [[, öffnet sich eine Auswahl mit den Notizen deines Workspace. Wählst du eine aus oder legst direkt aus der Auswahl eine neue an, landet im Dokument ein Knoten mit zwei Angaben:

  • noteId – die tatsächliche Kennung der Zielnotiz

  • fallbackTitle – der Titel zum Zeitpunkt des Einfügens

Die ID ist der Link. Der Ersatztitel ist nur eine Beschriftung für den Notfall.

Wird der Chip angezeigt, sucht er die Zielnotiz über die ID und zeigt ihren aktuellen Titel. Benennst du das Ziel um, aktualisiert sich jeder Chip, der darauf zeigt, überall und sofort. Nichts zu reparieren, kein Suchen und Ersetzen quer durchs Archiv, keine Liste „nicht aufgelöster Links“, die du am Sonntag abarbeiten musst.

Damit sind Links auch eindeutig, wie es Titel-Links nie sein können. Zwei Notizen können denselben Titel haben. Zwei Notizen können nicht dieselbe ID haben.

Weil Links als echte Referenzen gespeichert sind, gibt es die Gegenrichtung umsonst.

Bei jedem Speichern geht Notez das gespeicherte Dokument durch, sammelt die IDs der Notizen, auf die es verweist, und gleicht diese Menge mit dem bisherigen Stand ab: Neue Links werden eingetragen, entfernte gelöscht. Die Link-Tabelle ist eine reine Funktion deines Inhalts. Sie kann nicht von dem abweichen, was du tatsächlich geschrieben hast, weil sie bei jedem Speichern genau daraus neu aufgebaut wird.

Bei diesem Durchgang fallen ein paar Dinge heraus, jedes aus einem konkreten Grund:

  • Links auf sich selbst. Eine Notiz, die auf sich selbst verweist, ist keine Beziehung.

  • Ziele in anderen Workspaces. Nur Notizen aus demselben Workspace bleiben. Deshalb kann ein Link aus deinem Arbeits-Workspace nie verraten, dass eine private Notiz existiert, und zwar nicht wegen einer Regel, sondern konstruktionsbedingt.

  • Fehlerhafte IDs. Notizen aus einem Import können noch nicht aufgelöste Platzhalter-Verweise enthalten, solange der Import sie nicht fertig verknüpft hat. Solche Verweise werden verworfen, statt das Speichern scheitern zu lassen.

Backlinks sind dann einfach dieselbe Tabelle, andersherum gelesen: jede Notiz, deren Inhalt auf diese verweist. Es gibt keinen eigenen Backlink-Index, der neu aufgebaut werden müsste, und keinen Wartungsmodus. Der Bereich „Verknüpfte Notizen“ einer Notiz zeigt beide Richtungen.

Inline-Links mit [[ sind nicht der einzige Weg, auf dem Notizen aufeinander zeigen. Der andere ist die benutzerdefinierte Eigenschaft vom Typ Relation: ein typisiertes Feld an einer Notiz, dessen Wert eine andere Notiz ist. Zum Beispiel eine Eigenschaft Client an jeder Besprechungsnotiz, die auf die Notiz dieses Kunden zeigt.

Beide sehen ähnlich aus und werden völlig unterschiedlich gespeichert. Inline-Links landen beim Speichern in der Link-Tabelle. Relation-Links werden beim Lesen abgeleitet und dort nie eingetragen.

Der Grund ist ein Fehler, den ich nicht zweimal ausliefern will. Der Abgleich beim Speichern vergleicht die gesamte Link-Menge einer Notiz und löscht alles, was nicht im Inhalt vorkommt. Lägen die Links aus Relation-Eigenschaften in derselben Tabelle, würde das nächste Speichern des Inhalts das Dokument ansehen, sie dort nicht finden und löschen. Deine Client-Relationen würden eine Notiz nach der anderen verschwinden, genau in dem Moment, in dem die Notiz bearbeitet wird, also unbemerkt und nur bei deinen aktivsten Notizen.

Deshalb liegen die beiden Arten getrennt und werden beim Lesen vereinigt. Etwas mehr Arbeit pro Lesezugriff, dafür kann keine Art die andere still verschlucken.

Der praktische Unterschied für dich:

  • Inline-Links sind Text. Sie gehören mitten in den Satz, dorthin, wo die Verbindung ein Gedanke ist, den du gerade hast: „das folgt aus [[dem Retry-Postmortem]]“.

  • Relation-Eigenschaften sind Struktur. Sie passen, wenn jede Notiz einer Art denselben Verweis hat und du danach filtern und sortieren willst.

Nutze beide. Sie beantworten verschiedene Fragen.

Der Graph

Sobald Links echte Referenzen sind, ist eine Graphansicht nur eine Darstellung von Daten, die schon da sind, und nichts, was eigens gebaut werden muss. Den Bereich „Verknüpfte Notizen“ jeder Notiz kannst du als Liste oder als Graph ansehen: womit sie verbunden ist und was zurück auf sie verweist.

Eine Einschränkung gehört dazu: Eine Graphansicht hilft wirklich beim lokalen Erkunden, wenn du die Nachbarschaft einer Notiz sehen oder ein Cluster bemerken willst, das du nicht geplant hast. Als Darstellung des ganzen Archivs taugt sie viel weniger. Zehntausend Notizen als Wollknäuel sind ein Bildschirmschoner. Ich habe die lokale Variante gebaut.

Gibst du eine Notiz öffentlich frei, verhalten sich ihre Inline-Links vorsichtig. Die öffentliche Ansicht hat keinen Zugriff auf deinen Workspace, also zeigt ein Chip den fallbackTitle, der beim Einfügen gespeichert wurde. Hier hat die Notfall-Beschriftung endlich ihren Auftritt. Ein funktionierender Link wird der Chip nur, wenn auch die Zielnotiz öffentlich freigegeben ist.

Ist sie nicht freigegeben, erscheint der Chip als inaktiver, ausgegrauter Text. Er zeigt dem Leser, dass hier auf etwas verwiesen wird, ohne den aktuellen Titel zu verraten oder ihn an die Notiz heranzulassen.

Das ist die richtige Voreinstellung, und du solltest sie kennen, bevor du eine Notiz teilst: Eine geteilte Notiz zieht ihre verknüpften Notizen nicht mit in die Öffentlichkeit. Soll eine Gruppe verknüpfter Notizen lesbar sein, gibst du jede davon frei.

So nutzt du das im Alltag

Verlinken gehört zu den Funktionen, die man leicht überplant und dann nie benutzt. Was tatsächlich funktioniert:

  1. Verlinke beim Schreiben, nicht hinterher. In dem Moment, in dem du etwas tippst, das sich auf bereits Geschriebenes bezieht, weißt du, dass der Link existiert. Später erinnerst du dich nicht mehr.

  2. Verlinke nicht alles. Eine Notiz, auf die vierzig Stellen verweisen, sagt dir nichts. Links sind nur dann ein Signal, wenn sie sparsam gesetzt sind.

  3. Sieh dir die Backlinks an, bevor du eine neue Notiz schreibst. Öffne die Notiz zum Thema, schau, was schon auf sie verweist, und oft stellst du fest, dass du den Großteil der neuen Notiz vor acht Monaten schon geschrieben hast.

  4. Mach aus einem wiederholten Link eine Relation-Eigenschaft. Wenn du aus jeder Besprechungsnotiz von Hand auf die Notiz eines Kunden verlinkt hast, ist das kein Text mehr, sondern ein Feld. Mach eins daraus, dann bekommst du Filtern und Sortieren umsonst dazu.

  5. Benenne frei um. Genau darum geht es. Titel sind Beschreibungen, keine Kennungen, und du solltest sie verbessern können, sobald dir ein besserer einfällt.

Der letzte Punkt ist der unauffällige Vorteil von Links über die ID, und es dauert eine Weile, bis man ihn bemerkt. In einem System, das über Titel verlinkt, hörst du nach und nach auf umzubenennen, weil Umbenennen etwas kostet und du dir schon einmal die Finger verbrannt hast. Am Ende hast du ein Archiv voller Titel, mit denen du dich abgefunden hast.

Wenn Links eine Umbenennung überstehen, werden die Titel mit der Zeit besser.

Weiterlesen