Eine persönliche Wissensbasis als Klartext-Ordner: Inbox, Notizen, Quellen, Projekte, Archiv

Worum es geht

Eine persönliche Wissensbasis ist die Menge der Notizen, die eine Person oder ein Agent für den eigenen späteren Gebrauch schreibt: was gelernt, entschieden, ausprobiert und gelesen wurde. Als Klartext in einem versionierten Ordner geführt, überdauert sie jede Anwendung. Die hier vorgeschlagene Struktur trennt Inhalte nach Lebensdauer statt nach Thema:

• inbox/ — alles schnell und unverarbeitet Festgehaltene; sollte nach jeder wöchentlichen Durchsicht leer sein.
• notes/ — eine dauerhafte Idee pro Datei, in eigenen Worten geschrieben, mit Verlinkungen zu anderen Notizen und zu Quellen.
• sources/ — eine Datei pro Buch, Paper, Seite oder Gespräch, mit der Referenz, einer kurzen Zusammenfassung und der Liste der daraus entstandenen Notizen.
• projects/ — Arbeitsnotizen zu etwas mit einem Enddatum: Pläne, Protokolle, Entscheidungen, offene Fragen.
• archive/ — abgeschlossene Projekte und ersetzte Notizen, verschoben statt gelöscht, nie von notes/ aus verlinkt.

Jede Datei beginnt mit einem kleinen Kopfbereich (Kennung, Titel, Erstellungsdatum, Tags, Status) und trägt ihre Kennung im Dateinamen, damit Verlinkungen eine Umbenennung überstehen. Eine index.md ganz oben listet Einstiegspunkte nach Thema und wird von Hand gepflegt; eine Volltextsuche deckt den Rest ab.

Warum es wichtig ist

Notizen, die in einer Anwendung leben, gehen verloren, wenn die Anwendung wechselt; nach Thema sortierte Notizen werden jedes Mal umsortiert, wenn sich die Themen verschieben, was Verlinkungen bricht. Die Sortierung nach Lebensdauer hält die Entscheidung beim Ablegen trivial (ist dies eine Quelle, eine Idee, ein Projekt?) und macht die wöchentliche Pflege konkret: Inbox leeren, abgeschlossene Projekte verschieben, Index aktualisieren.

So wird es angewendet

• Die Baumstruktur flach halten: keine Unterordner unter notes/ und sources/; stattdessen Tags und Verlinkungen verwenden.
• Die Notiz schreiben, bevor die Quelle abgelegt wird, nicht umgekehrt; eine Quelle ohne Notiz ist ein Lesezeichen.
• CommonMark verwenden, mit einer Überschrift pro Notiz und relativen Links, damit jeder Viewer oder die Dateiwerkzeuge eines Agenten sie lesen können.
• Den Ordner versionieren (git oder eine synchronisierte Kopie mit Verlauf) und nach jeder Durchsicht committen.
• Bei einem Agenten notes/ als dauerhaftes Gedächtnis und projects/ als Notizblock behandeln; beim Sitzungsstart den Index laden, nicht den gesamten Baum.

Stolpersteine

Eine wachsende inbox/, die nie verarbeitet wird. Notizen, die Quellen abschreiben, statt eine Idee zu formulieren. Ein Index, der alles auflistet und damit nichts. Löschen statt Archivieren, was Verlinkungen aus älteren Notizen und aus Projektprotokollen bricht. Verschachtelte Ordner nach Thema "nur für diesen Bereich", was das Problem wieder einführt, das die Struktur vermeidet.

Archivieren, ohne Verlinkungen zu brechen

Verlinkungen zwischen Notizen erfolgen über die Kennung, nie über den Pfad, und ein Link wird aufgelöst, indem jeder Ordner durchsucht wird, archive/ eingeschlossen. Eine Notiz nach archive/ zu verschieben, bricht dann nichts, und die Regel "nie ins Archiv verlinken" ist überflüssig: Das Archiv ist ein Filter für den Index und für die Standardsuche, keine Grenze für Verlinkungen. Eine ersetzte Notiz behält ihre Kennung und erhält eine Kopfzeile superseded_by: <identifier>, sodass eine lesende Person, die einem alten Link folgt, zum Ersatz weitergeleitet wird; ein abgeschlossenes Projekt behält sein Protokoll unverändert. Die Ausnahme ist inbox/: Ein Eintrag, der nie verlinkt und nie verarbeitet wurde, kann gelöscht werden, denn der einzige Grund, Dateien zu behalten, ist der Schutz von Verlinkungen darauf.