Johnny Decimal trifft Obsidian: zwei Systeme in einem Vault
11. August 2026
Diesen Beitrag habe ich zum Großteil von KI schreiben lassen. Dies ermöglicht es mir, ältere Projekte aufzuarbeiten und zu dokumentieren.
Kurzfassung: Johnny Decimal ordnet über Ordner, Steph Angos Vault-System über Metadaten. Beide haben recht — für unterschiedliche Dinge. Ich benutze beide nebeneinander, mit einer Trennlinie, die sich in einem Satz sagen lässt.
Der letzte Teil meiner Serie, und der einzige ohne Server. Vorher habe ich meine Dateien mit Johnny Decimal sortiert — hier geht es um die Frage, was davon in einem Notizen-Vault überhaupt sinnvoll ist.
1. Zwei Systeme, ein Vault
Mein Vault lief ursprünglich komplett auf Johnny Decimal. Jede Notiz bekam eine Nummer, jede Nummer einen Platz im Ordnerbaum. Das funktionierte für Verträge und Steuerunterlagen hervorragend — und für Notizen überhaupt nicht.
Der Grund liegt in der Natur der Sache. Ein Vertrag liegt irgendwo. Ein Gedanke nicht.
Parallel dazu gibt es Steph Angos Vault-System, das die entgegengesetzte Position vertritt: Ordner vermeiden, alles über Metadaten und Verlinkung erschließen. Jede Notiz trägt eine categories-Eigenschaft, und Abfragen erzeugen die Sichten, die man sonst über Ordner bauen würde.
Ich habe lange versucht, mich für eins von beidem zu entscheiden. Die Auflösung war, dass die Frage falsch gestellt war.
2. Der eigentliche Konflikt: Ordner gegen Metadaten
Beide Systeme lösen dasselbe Problem — wo finde ich das wieder — mit gegensätzlichen Mitteln.
Johnny Decimal ist Folder-Primary. Die Ordnerstruktur ist die Wahrheit. Eine Datei hat genau einen Platz, und dieser Platz hat eine Nummer, die sich nie ändert. Der Gewinn ist Eindeutigkeit: Es gibt keine zwei Orte, an denen etwas liegen könnte.
Stephs System ist Metadata-First. Der Speicherort ist egal, die Eigenschaften zählen. Eine Notiz kann gleichzeitig in mehreren Sichten auftauchen, weil Sichten aus Abfragen entstehen statt aus Ordnern.
Der Konflikt ist real und lässt sich nicht wegdiskutieren. Was ihn auflöst, ist die Erkenntnis, dass die beiden Systeme unterschiedliche Objekte meinen.
Eine Rechnung existiert als Datei. Sie hat einen physischen Ort, sie wird archiviert, sie muss in zehn Jahren auffindbar sein — auch ohne Obsidian, auch im Dateimanager. Für sie ist ein fester Ort ein Vorteil.
Ein Gedanke über ein Buch existiert nicht als Datei, sondern als Knoten in einem Netz. Er gehört gleichzeitig zum Buch, zum Thema, zu dem Projekt, das er ausgelöst hat, und zu dem Tag, an dem ich ihn hatte. Ihn in einen Ordner zu zwingen heißt, drei dieser vier Beziehungen wegzuwerfen.
3. Die Trennlinie
Die Regel, auf die es hinausläuft, passt in einen Satz:
Eine Johnny-Decimal-Nummer bekommt nur, was einen echten Speicherort braucht. Alles, was als Notiz lebt, läuft über
categories.
Praktisch heißt das:
| Johnny Decimal | Categories | |
|---|---|---|
| Was | Verträge, Bewerbungen, Steuerunterlagen, Projektordner | Journal, Bücher, Projekte, Meetings, Kurse, Werkzeuge |
| Wo | ein fester Ordner, gespiegelt im Dateisystem | irgendwo im Vault, Ort egal |
| Erschlossen über | die Nummer | Abfragen über Eigenschaften |
| Ändert sich | nie | ständig |
Der Test, den ich mir angewöhnt habe: Gäbe es das Ding auch ohne Obsidian? Ein PDF gäbe es auch dann. Eine Notiz über einen Gedanken nicht.
Zwei Konsequenzen, die sich daraus ergeben und die ich anfangs nicht gesehen habe:
Die Ordner mit den Nummern spiegeln reale Ordner im Dateisystem — bei mir in dem Cloud-Speicher, in dem die Dokumente tatsächlich liegen. Beide Seiten heißen identisch. Das ist der eigentliche Zweck: Die Notiz ist ein Index auf etwas, das außerhalb existiert.
Nummerierte Notizen bekommen ausdrücklich keine categories. Sonst hätte man zwei konkurrierende Ordnungssysteme auf demselben Objekt — und müsste bei jeder Notiz entscheiden, welches gilt. Genau die Entscheidung, die der Hybrid abschaffen soll.
4. Das dreistufige Verlinkungsmodell
Die Nummernstruktur hat drei Ebenen — Area, Kategorie, ID. Damit man von einer beliebigen Notiz aus dorthin navigieren kann, verlinkt jede Ebene auf die nächste:
Notiz ──jd──▶ ID-Notiz ──category──▶ Kategorie-Notiz ──area──▶ Area-Notiz
Eine Notiz über ein Projekt trägt also ein jd-Feld, das auf die passende ID-Notiz zeigt. Die ID-Notiz zeigt auf ihre Kategorie, die Kategorie auf ihre Area. Drei Abfragen erzeugen daraus die Übersichten: alle Notizen zu einer ID, alle IDs einer Kategorie, alle Kategorien einer Area.
Eine Vereinfachung, auf die ich erst später gekommen bin: Die ID-Notizen selbst tragen kein jd-Feld mehr. Ihre Adresse steht bereits im Dateinamen — sie auf sich selbst zeigen zu lassen war eine Selbstreferenz, die nichts erklärt und die erste Abfrage kaputtgemacht hat.
Klingt trivial. Der Fehler lag darin, das Feld mechanisch überall zu setzen, statt zu fragen, was es eigentlich aussagt: „diese Notiz gehört zu jener Adresse“. Bei der Adresse selbst ist die Aussage leer.
5. Templates und geteiltes Vokabular
Fast jede Notiz startet aus einem Template. Die tragen zwei Dinge: die categories-Zuordnung und die Frontmatter-Felder, nach denen man später filtern will.
Die Regel, die den größten Unterschied macht, ist von Steph übernommen und leicht zu unterschätzen:
Eigenschaftsnamen und -werte werden über Kategorien hinweg wiederverwendet, nicht pro Kategorie neu erfunden.
Wenn genre bei Büchern, Filmen und Serien gleich heißt und gleich befüllt wird, kann man kategorienübergreifend filtern. Erfindet jede Kategorie ihr eigenes Vokabular, hat man dieselbe Zersplitterung wie bei Ordnern — nur unsichtbar.
Genau dieser Fehler ist mir passiert, als ich zwei neue Templates gebaut habe: Beide brauchten ein Statusfeld, und beide hätten ohne Abgleich unterschiedliche Werte benutzt. Aufgefallen ist es nur, weil ich sie gleichzeitig angelegt habe. Bei zwei Wochen Abstand hätte ich es nie gemerkt.
Seitdem gibt es ein gemeinsames Statusvokabular für alle Kategorien: idea, evaluating, in-progress, done, deprecated.
Templates sind komponierbar, nicht exklusiv. Ein Autoren-Template und ein Personen-Template tragen beide dieselbe Kategorie und unterscheiden sich über ein zusätzliches type-Feld. Das erspart eine Kategorie pro Rolle.
6. Wann ein Datum in den Dateinamen gehört
Eine kleine Frage mit einer überraschend falschen ersten Antwort.
Meine erste Regel war: Datum im Dateinamen für alles, was per Schnellerfassung entsteht. Klang plausibel und war falsch.
Die richtige Regel knüpft das Datum an das Template, nicht an die Erfassungsmethode:
- Journal-Notizen →
YYYY-MM-DD Titel, mit Uhrzeit wenn bekannt. Egal, ob unterwegs per Hotkey erfasst oder Wochen später nachgetragen. - Meetings → ebenfalls mit Datum, aber aus einem anderen Grund: Meeting-Titel wiederholen sich stark. Ohne Datum wären drei Notizen namens „Sprint Planning“ nicht unterscheidbar.
- Alles andere → nur der Titel. Das Erstellungsdatum steht im Frontmatter, wo es hingehört.
Der Unterschied ist nicht kosmetisch. Die Erfassungsmethode ist eine Eigenschaft des Moments, das Template eine Eigenschaft des Inhalts. Eine Regel, die an der Methode hängt, produziert zwei verschieden benannte Notizen für denselben Inhaltstyp — je nachdem, wie eilig man es gerade hatte.
Bei Evergreen-Notizen fällt das Datum aus Prinzip weg: Sie sollen zeitlos sein. Ein Datum im Titel legt nahe, dass sie an einen Moment gebunden sind.
7. Was ich unterwegs falsch gemacht habe
Ordner umbenannt, ohne die Konfiguration zu prüfen
Ich habe die Hauptordner umnummeriert und dabei vier Konfigurationsdateien zerschossen. Obsidian speichert Ordnernamen in .obsidian/*.json als feste Zeichenketten — für Daily Notes, Templates und Anhänge. Beim Umbenennen zieht es die nicht mit.
Steht jetzt als Warnung in meinen eigenen Konventionen. Ordnerumbenennungen sind in Obsidian keine reine Dateioperation.
Daily Notes als Journal missbraucht
Stephs Regel: Daily Notes bleiben leer und existieren nur als Ziel für Rückverweise. Bei mir enthielten rund 206 davon echten Journalinhalt — Gedanken, Notizen, halbe Absätze, alles chronologisch aufgeschichtet.
Die Migration in rund 260 einzelne Notizen war die aufwendigste Einzelmaßnahme des ganzen Umbaus, und ich habe sie bewusst nicht mechanisch gemacht. Ein Tag mit fünf Gedanken wird nicht automatisch zu fünf Notizen — manche gehören zusammen, manche sind unter zwei Zeilen und gehören nirgendwo hin.
Warum der Aufwand: Ein Gedanke in einer Tagesdatei ist nicht verlinkbar. Er hat keinen Titel, keine Kategorie, keine Beziehungen — er ist nur ein Absatz an einem Datum. Erst als eigene Notiz wird er zu etwas, worauf man zeigen kann.
Rund 78 weitere Notizen bestanden ausschließlich aus einem Zeiteintrag. Die sind in einer gemeinsamen Datei gelandet — eine Zeile pro Tag statt einer Datei pro Eintrag.
Zwei READMEs, wo eines gereicht hätte
Ich hatte die Vault-Übersicht und die Template-Referenz getrennt. Beide beschrieben Regeln, beide wurden bei Änderungen angefasst, und regelmäßig stand die Antwort im jeweils anderen Dokument. Zusammengeführt.
Dieselbe Lehre wie bei der Landkarten-Notiz im Datei-Artikel: Ein Dokument, das zwei Systeme zusammenhält, ist meistens ein Symptom davon, dass die Trennung an der falschen Stelle liegt.
References und Root nicht sauber getrennt
Notizen über Personen, Orte und Werkzeuge lagen im Hauptbereich zwischen meinen eigenen Notizen. Das Kriterium, das das auflöst, ist nicht Länge oder Wichtigkeit:
Existiert das Ding auch ohne mich? Bücher, Filme, Orte, Personen, Firmen, Werkzeuge → References. Journal, Projekte, Meetings, eigene Gedanken → Hauptbereich.
Ein Buch, das ich lese, gehört nach References. Meine Notizen über das Buch gehören in den Hauptbereich. Das klingt spitzfindig, macht aber den Unterschied zwischen einem Katalog und einem Denkwerkzeug.
8. Wo der Hybrid an seine Grenzen kommt
Der ehrliche Schluss: Zwei Fragen beantwortet auch dieses System nicht.
Archivierung. Bei den nummerierten Ordnern signalisiere ich Abschluss über ein zweites Datum im Namen. Für Notizen gibt es kein Äquivalent — eine abgeschlossene Projektnotiz sieht aus wie eine laufende, solange niemand das Statusfeld pflegt. Und Statusfelder pflegt man nur, solange man daran denkt.
Mehrfachzugehörigkeit bei Dateien. Genau das Problem, das die Nummern lösen sollten, kommt an den Rändern zurück. Bestimmte Buchhaltungsunterlagen könnten unter zwei Kategorien liegen; ich habe mich für eine entschieden und die Entscheidung dokumentiert. Das ist keine Lösung, sondern eine festgehaltene Willkür.
Bei Notizen stellt sich die Frage nicht — die dürfen zu beliebig vielen Kategorien gehören. Das ist der beste Beleg dafür, dass die Trennlinie richtig liegt: Wo Mehrfachzugehörigkeit natürlich ist, sind Metadaten das richtige Werkzeug. Wo ein Ding physisch an einem Ort liegen muss, sind es Ordner.
Würde ich es wieder so machen? Ja — aber ich würde die Trennlinie zuerst ziehen und dann anfangen. Ich habe es umgekehrt gemacht: erst alles in ein System gezwungen, dann gemerkt, dass es für die Hälfte nicht passt, dann umgebaut. Der Umbau war die Arbeit. Die Regel dahinter war ein Nachmittag Nachdenken.
Weiterführende Artikel
- Mein Johnny-Decimal-System für Dateien und Ordner — die andere Hälfte: reine Datei- und Ordnerorganisation
- Immich Fotobackup einrichten — Fotos selbst hosten
- Stalwart Mail Server einrichten — Mail, Kalender und Kontakte
- Ein VPS, sieben Dienste, ein Repo — der Serieneinstieg: der Server, der hinter den anderen Artikeln steht.
Quellen
- stephango.com/vault — das Metadata-First-System, inklusive kepano-obsidian als Vorlage
- How I use Obsidian — die Regelsammlung dahinter
- johnnydecimal.com — das Folder-Primary-Gegenstück
- Obsidian Bases — die Abfragen, über die die Kategorien-Sichten entstehen