Obsidian-Vault organisieren: Frontmatter, Templates und Dataview

Im ersten Teil habe ich erklärt, warum Obsidian bei mir Evernote und Todoist abgelöst hat und warum ich PARA dem Zettelkasten vorziehe. Was dort nur als Versprechen stehenblieb: wie aus dem Vault – dem Ordner voller .md-Dateien – etwas wird, das sich wie eine Strukturierung anfühlt. Das hole ich jetzt nach.

Vorweg, damit klar ist, worum es nicht geht. Das hier ist keine Plugin-Galerie. Es geht um drei Dinge, die ineinandergreifen – eine Ordnerstruktur, die man nicht jede Woche neu überdenkt, ein Frontmatter, das jede Notiz maschinenlesbar macht, und Dataview, das daraus Dashboards baut. Am Ende lege ich dir mein Standard-Template und mein Inbox-Dashboard als kostenlosen Download dazu. Beide laufen bei mir produktiv.

Die Ordnerstruktur: PARA, aber mit Nummern

In Teil 1 stand noch eine Struktur mit leicht anderen Ordnernamen – 0 Inbox, 1 Projekte, 2 Gedankenund so weiter. Diese habe ich seitdem aufgeräumt und noch etwas näher an der PARA-Struktur ausgerichtet. Heute sieht die oberste Ebene so aus:

• 0 Inbox
• 1 Projekte
• 2 Bereiche
• 3 Ressourcen
• 4 Archiv
• 5 System (Für Templates, Vorlagen, etc.)

Die Nummer ist kein Selbstzweck. Sie erzwingt die Reihenfolge im Datei-Explorer, und die Reihenfolge bildet den Workflow ab: Alles startet in 0 Inbox, wandert nach der Triage in einen Projekt-, Bereichs- oder Ressourcen-Ordner und landet irgendwann in 4 Archiv oder im Papierkorb. Wer schon mal versucht hat, alphabetisch sortierte Ordner gegen die eigene Denkrichtung zu lesen, weiß, warum die Null vorne steht.

Die zweite Achse läuft quer zu den Ordnern: die domain. Sie steckt im Frontmatter, nicht im Pfad, und trennt meine Lebens- und Arbeitsbereiche – Web-Dev, Business, Blog, Private. Eine Notiz liegt also physisch in 1 Projekte, gehört aber logisch zur Domain Blog. Diese Trennung von Ablageort und Themenzugehörigkeit ist der Trick, der Dataview später überhaupt erst nützlich macht.

Das Frontmatter-Template

Jede Notiz bekommt beim Anlegen denselben Kopf. Das übernimmt das native Templates-Plugin – kein Community-Plugin nötig. Mein Standard-Template:

---
type:
domain:
status:
created:
updated:
ai:
tags: []
---

# {{title}}

## Exzerpt

Zusammenfassung

## Inhalt

Der {{title}}-Platzhalter ist eine Variable des Templates-Plugins. Beim Einfügen ersetzt Obsidian sie durch den Dateinamen. {{date}} und {{time}} gäbe es auch, aber genau hier liegt eine Grenze, die man kennen sollte: Das native Plugin fügt nur einmalig ein. Ein updated-Feld, das sich bei jeder Änderung selbst fortschreibt, kann es nicht abbilden.

Diese Aufgabe übernimmt bei mir der Linter. Seine YAML-Timestamp-Regel schreibt created beim ersten Speichern und updated bei jedem weiteren – automatisch, im Hintergrund, ohne dass ich daran denken muss.

Zu den Feldern selbst, kurz:

• type trennt Notiz, Ressource, kurze Notiz und so weiter.
• domain ordnet dem Lebens- oder Arbeitsbereich zu.
• status bildet den Reifegrad ab, von seedling (frisch rein) über in progress bis completed oder evergreen.
• ai „steuert“ über ein Rechtesystem, was Claude Code und das Gemini CLI mit dem Dokument anstellen dürfen. Dazu kommt in Teil 4 alles Weitere.

Klingt nach Overhead. Ist es in den ersten zwei Tagen auch. Danach tippt man den Header nicht mehr, man füllt ihn – und der Gewinn kommt im nächsten Schritt.

Metadata Menu: Frontmatter ohne YAML-Friemeln

Felder von Hand zu tippen ist fehleranfällig. Schreibt man einmal in progres statt in progress, fällt die Notiz aus jeder Abfrage, die auf den korrekten Wert filtert – und man sucht den Fehler erst, wenn das Dashboard lügt. Genau dafür gibt es Metadata Menu.

Das Plugin definiert Felder mit festem Typ und festen Werten. Mein status ist ein Select-Feld mit genau den vier erlaubten Werten. Beim Bearbeiten klicke ich den Wert aus einem Dropdown, statt ihn zu tippen. Alternativ gibt es auch eine Autovervollständigung im Obisdian-Editor. domain genauso. Tippfehler im Frontmatter sind damit konstruktionsbedingt unmöglich.

Der zentrale Begriff dabei heißt fileClass. Eine fileClass ist eine Notiz, die ein Set von Feldern und deren Regeln beschreibt – und über Ordnerpfad, Tag oder eine eigene Abfrage automatisch auf Notizen angewendet wird. Eine fileClass für meine Blog-Beiträge legt fest, dass status, domain und tags vorhanden sein müssen und welche Werte sie annehmen dürfen. Die Felder lassen sich dann per Rechtsklick bearbeiten, ohne die Datei überhaupt zu öffnen.

Ein ehrliches Wort dazu: Der Entwickler von Metadata Menu hat öffentlich gemacht, dass er kaum noch Zeit für das Plugin hat und Mitstreiter sucht. Es läuft stabil und kann mehr als alles, was ich sonst gesehen habe – aber wer 2026 neu anfängt, sollte wissen, dass Obsidian mit den nativen Properties (seit Version 1.4) einen Teil der Basisarbeit inzwischen selbst erledigt. Für reines Dropdown-Komfort-YAML braucht man das Plugin nicht zwingend. Für typisierte Felder mit Validierung und fileClass-Logik schon.

Dataview: der Vault wird abfragbar

Bis hierhin habe ich nur sauber befülltes Frontmatter. Der Hebel, der daraus eine Datenbank macht, ist Dataview. Das Plugin liest die Frontmatter-Felder aller Notizen ein und macht sie über eine Abfragesprache zugänglich – DQL, eine Art SQL für den Vault.

Ein einfaches Beispiel. Diese Abfrage listet alle Notizen aus der Inbox, die zur Domain Business gehören, sortiert nach letzter Änderung:

```dataview
TABLE status, updated
FROM "0 Inbox"
WHERE domain = "Business"
SORT updated DESC
```

Das Ergebnis ist eine Tabelle, die sich live aktualisiert, sobald sich eine Notiz ändert. Für die meisten Übersichten reicht DQL aus.

Wird es komplexer – Gruppierungen, Schleifen, Bedingungen über mehrere Felder – wechsle ich zu DataviewJS. Statt der Abfragesprache schreibt man dann JavaScript gegen die Dataview-API. Ein Ausschnitt, der alle Notizen findet, denen Domain oder Typ fehlen:

```dataviewjs
const inbox = dv.pages('"0 Inbox"').where(p => p.type != "MOC");

const triage = inbox
  .where(p => !p.domain || !p.type)
  .sort(p => p.created, 'desc');

dv.table(["Notiz", "Status", "Erstellt"],
  triage.map(p => [p.file.link, p.status || "🌱 seedling", p.created || "—"]));
```

Das ist der Kern dessen, was mein Inbox-Dashboard tut – nur dass dort mehrere solcher Blöcke zusammenspielen.

Das Inbox-Dashboard, Stück für Stück

Mein Dashboard ist eine einzige Notiz mit mehreren DataviewJS-Blöcken. Jeder beantwortet eine Frage, die ich mir sonst manuell stellen müsste. Der Reihe nach:

Triage. Welche Notizen haben noch keine Domain oder keinen Typ? Das ist der Block von oben. Solange dort etwas steht, ist die Inbox nicht abgearbeitet.

Inbox Zero. Was liegt länger als 30 Tage in der Inbox herum? Diese Liste ist mein schlechtes Gewissen in Tabellenform. Alles, was hier auftaucht, gehört einsortiert oder gelöscht.

Bereichs-Übersicht. Pro Domain eine eigene Tabelle. Hier konfiguriere ich die Domains zentral an einer Stelle:

```dataviewjs
const domains = ["Web-Dev", "Business", "Blog", "Private"];
```

MOC-Übersicht. Eine Liste aller Maps of Content im Vault. MOCs sind Index-Notizen, die zusammengehörige Themen bündeln – das navigierbare Inhaltsverzeichnis, das mit dem Vault mitwächst.

Struktur-Check. Welche Notizen sind verwaist, hängen also an keiner einzigen anderen Notiz? Verwaiste Notizen sind kein Drama, aber ein Hinweis: Entweder fehlt eine Verknüpfung, oder die Notiz gehört ins Archiv.

Dazu kommt ein zweiter Block mit der Vault-Statistik – Dateien und Wörter pro Ordner, mit kleinen Fortschrittsbalken. Reine Spielerei, zugegeben. Aber sie zeigt auf einen Blick, wo sich das Material sammelt.

Das komplette Dashboard hängt unten als Download, zusammen mit dem Standard-Template – beides kostenlos. Es ist kommentiert, du kannst die Domains und Ordnernamen an dein eigenes Setup anpassen und die Blöcke einzeln übernehmen, die dir etwas bringen.

Dataview, Datacore oder Bases?

Eine Frage drängt sich 2026 auf, und ich will sie nicht unter den Tisch fallen lassen. Dataview ist das meistgenutzte Plugin seiner Art, aber die Entwicklung steht weitgehend still. Der designierte Nachfolger heißt Datacore, kommt vom selben Entwickler, ist deutlich schneller und erlaubt editierbare Tabellen – steckt aber noch in der Beta und lässt sich nur über Umwege installieren.

Parallel hat Obsidian mit Bases ein natives Core-Plugin bekommen, das Tabellen-, Listen- und Kartenansichten direkt aus den Properties baut. Kein Plugin, keine Abfragesprache, einfach an Bord. Für viele Standard-Dashboards ist das heute der naheliegende Weg.

Warum ich trotzdem vorerst bei Dataview bleibe

Mein Dashboard läuft, es nutzt DataviewJS-Logik, die sich in Bases aktuell nicht eins zu eins abbilden lässt, und ein Migrationsprojekt ohne konkreten Schmerz ist verschwendete Zeit. Wer aber heute neu aufsetzt und vor allem filterbare Übersichten will, sollte sich zuerst Bases anschauen, bevor er/sie eine Abfragesprache lernt. Bases verdient einen eigenen Artikel, den hebe ich mir auf.

Was als Nächstes kommt

Damit steht das Fundament: strukturierte Ordner, sauberes Frontmatter, abfragbare Dashboards. Im nächsten Teil geht es darum, wie das „Material“ automatisch ins Vault kommt – über n8n-Workflows, die Sprachnachrichten transkribieren, URLs und YouTube-Videos zusammenfassen und alles als fertiges Markdown mit korrektem Frontmatter ablegen.

Im vierten Teil verbinde ich den Vault über MCP mit Claude Code und dem Gemini CLI und lasse das frisch gebündelte Obsidian-CLI mitspielen. Dann wird das ai-Feld aus dem Frontmatter endlich zu dem, wofür es da ist.

Beiträge der Serie:

• Obsidian – mein digitales Gehirn, und warum ich nie wieder zurück möchte