Dass man Obsidian recht vielfältig einsetzen kann, ist für die Leserinnen und Leser dieses Blogs vermutlich nichts Neues. Aber dass man mit dem Dataview-Plugin aus der eigenen Notizensammlung alle möglichen Daten extrahieren und so den vielseitigen Markdown-Editor auch als Datenbank verwenden kann, vielleicht schon. Um das Ganze etwas praktischer zu machen, wird in diesem Beitrag als Anwendungsbeispiel erklärt, wie man mit dem Dataview-Plugin eine Leseliste in Obsidian erstellt.

---

Dataview ist eine externe Erweiterung, mit der aus dem Obsidian-Vault eine Datenbank wird. Das Plugin ermöglicht das Erstellen von dynamischen Ansichten und Abfragen, die auf den Metadaten und Inhalten der Notizen basieren. Mit Dataview können also über eine JavaScript-API und eine Pipeline-basierte Abfragesprache zum Filtern, Sortieren und Extrahieren von Daten beispielsweise Listen, Tabellen oder Kalenderansichten erstellt werden, die sich automatisch aktualisieren, sobald neue Notizen hinzugefügt oder bestehende Notizen geändert werden.

Funktionsweise

Dataview generiert Daten, indem es Informationen aus den Metadaten, also dem YAML-Frontmatter bzw. den Properties und Inline-Feldern abruft. Diese Metadaten sind zu Beginn des Markdown-Dokuments in den Properties enthalten. Inline-Felder sind ein spezifisches Feature von Dataview, das es ermöglicht, Metadaten auch direkt in den Text der Markdown-Datei in der Syntax Key:: Wert zu schreiben. Über entsprechende Abfragen, die mit der Dataview-Abfragesprache DQL erstellt werden, können dynamische Listen, Tabellen oder Kalenderansichten erzeugt werden. So kann mit Dataview zum Beispiel eine einfache Liste der offenen Aufgaben aus der Datei Aufgaben.md mit dem folgenden Code erzeugt werden:

```dataview
   TASK from "Aufgaben"
   WHERE !completed

Die Abfragesprache DQL ist eine sogenannte Pipeline-basierte Ausdruckssprache, die vage an SQL erinnert. Eine vollständige Beschreibung aller Funktionen, Anweisungen und Beispiele gibt es in der Dokumentation von Dataview. DQL-Ausdrücke funktionieren auch, wenn man sie quasi als Inline-Abfragen direkt in Markdown einbettet. Und wenn DQL zu wenig leistungsfähig ist, kann man in Dataview-Abfragen auch DataviewJS nutzen. Mit der leistungsstarken JavaScript-API bekommt man Zugriff auf den Dataview-Index und einige praktische Rendering-Werkzeuge. DataviewJS funktioniert übrigens genau wie DQL auch inline und ermöglicht so das Ausführen beliebiger Java Scripts direkt in Markdown. Damit lässt sich beispielsweise die Anzahl der im eigenen Obsidian-Vault gespeicherten Notizen mit einem kurzen inline-JavaScript ermitteln und direkt im Text einer Notiz ausgeben.

   Anzahl der Notizen im Vault: `$=dv.pages().length`
   Notizen mit dem Schlagwort "Rezept": `$=dv.pages("#Rezept").length`

Anwendungsbeispiel

Einer der Vorteile der mit Dataview erzeugten dynamischen Ansichten ist deren automatische Aktualisierung. Das ist für alle Arten von Statistiken, Aufgabenlisten oder Leselisten besonders nützlich. Deshalb sind die Einsatzgebiete für das Dataview-Plugin vielfältig und reichen von einfachen Listen bis hin zu Literaturverzeichnissen für Forscher, Studenten und Wissensarbeiter. Ein beliebter Anwendungsfall ist die Leseliste, also eine Liste der Bücher, die man noch lesen möchte und jener, die man bereits gelesen hat. Mit Dataview ist es möglich, diese Leseliste automatisch aus den Metadaten der einzelnen Buchnotizen zu generieren und aktuell zu halten.

Voraussetzung dafür ist, dass man für jedes Buch eine eigene Buchnotiz angelegt hat. In den Buchnotizen sind im YAML-Frontmatter bzw. in den Properties die notwendigen Daten gespeichert. Das Datensammeln beim Anlegen einer Buchnotiz kann man sich vom Book Search-Plugin abnehmen lassen.

In der Leseliste generiert man mit Dataview eine Tabelle mit der folgenden DQL-Abfrage:

```dataview
TABLE WITHOUT ID "![anyName|50](" + cover + ")" AS " ", link(file.link, title) as Titel, author AS "Autor", "[" + type + "](" + link + ")" AS "Typ", started AS "begonnen", status AS "Status"
FROM "Interessen/Lesen"
WHERE status = "ungelesen"
SORT created DESC

In dieser Abfrage wird in den ersten drei Zeilen die Tabelle konfiguriert. Danach wird in der vierten Zeile der Suchbereich auf das Verzeichnis Interessen/Lesen im Obsidian-Vault eingegrenzt und in der fünften Zeile wird definiert, dass nur jene Bücher in der Tabelle aufgelistet werden, deren Status in den Properties auf ungelesen gesetzt ist. In der sechsten Zeile wird abschließend die Sortierreihenfolge festgelegt, und zwar absteigend nach dem Erstelldatum, das in den Properties unter created eingetragen wird, sodass die zuletzt erstellte Buchnotiz ganz oben in der Tabelle aufscheint.

Zur Tabelle ist in diesem Beispiel anzumerken, dass die Zeilennummern mit dem Befehl WITHOUT IDausgeblendet werden. Danach werden die einzelnen Spalten und Spaltenüberschriften definiert. Die DQL-Syntax dafür ist grundsätzlich immer Datenquelle AS "Spaltenüberschrift". Zum Beispiel wird der Name des Autors in den Properties der Buchnotizen unter author eingetragen. Wenn man diesen Namen nun in der Leseliste in der Spalte Autoranzeigen möchte, dann definiert man das mittels author AS "Autor". Die einzelnen Spalten in der Tabelle werden in der DQL-Abfrage durch Beistriche voneinander getrennt.

Grafiken und Links können ebenfalls dargestellt werden. In der Leseliste wird in der ersten Spalte jeweils das Coverbild des Buchs mit einer Höhe von 50 Pixeln angezeigt. Die Spalte soll zudem keine Spaltenüberschrift bekommen. Das Anzeigen der Grafik erinnert dabei an die Markdown-Syntax und wird mit "![anyName|50](" + cover + ")" AS " " bewerkstelligt. Der Ausdruck " + cover + " in den runden Klammern fügt dort den Link ein, der in den Properties der Buchnotizen unter cover gespeichert wird. Mit AS " " bleibt die Spaltenüberschrift leer.

Bei Links gilt es, zwischen internen und externen Links zu unterscheiden. Anders, als in der Obsidian-spezifischen Markdown-Syntax werden interne Links nicht über doppelte eckige Klammern erzeugt, sondern folgen in der DQL-Abfragesprache einer anderen Syntax. In unserem Beispiel soll der Link zur jeweiligen Buchnotiz in der Spalte Titel neben dem Cover des Buches angezeigt werden. Die DQL-Syntax dafür lautet link(file.link, title) as Titel. Anders als bei den übrigen Spaltenausdrücken werden hier die Spaltenüberschrift nicht unter Anführungszeichen gesetzt und zudem das as nicht in Blockbuchstaben, sondern kleingeschrieben. Und dass nicht der Dateiname, sondern Buchtitel als Linktext angezeigt wird, definiert man direkt im Link-Klammerausdruck, indem man von dort nach file.link auf das Feld title in den Properties der jeweiligen Buchnotiz verweist.

Externe Links, beispielsweise zu Webseiten oder Dateien, folgen wiederum der auch von Markdown gewohnten Syntax [Linktitel](Linkadresse). In der Leseliste werden externe Links in der Spalte Typ genutzt, um von dort entweder zum Buch im Webshop der Buchhandlung des Vertrauens oder – sofern schon gekauft – direkt zum E-Book am Computer zu gelangen. Diese Links werden in den Buchnotizen in den Properties unter link gespeichert, der Buchtyp unter type. Daraus kann dann über die DQL-Syntax "[" + type + "](" + link + ")" AS "Typ" der Link in der Spalte Typ ausgegeben werden.

Je nach Status eines Buches können dann noch weitere Tabellen in der Leseliste angelegt werden, zum Beispiel für die Bücher, die man gerade liest, oder jene, die als nächstes gelesen werden sollen, sowie die bereits gelesenen Bücher. Dabei gilt es zu beachten, dass man den Status des Buches in der jeweiligen Buchnotiz aktuell hält und im Properties-Feld status beispielsweise zwischen ungelesen, gelesen, nächstes und lesen unterscheidet.

Einstellungen

Die Einstellungsmöglichkeiten für Dataview sind wenig überraschend ähnlich aufgebaut, wie bei den meisten anderen externen Erweiterungen auch.

Unter General Settings kann man die verschiedenen Abfragen aktivieren oder deaktivieren. Im darauffolgenden Abschnitt Codeblock Settings werden Vorgaben für Schlüsselwörter und Präfixe gemacht, die vor allem die Inline-Codeblöcke einleiten.

Im dritten Abschnitt View Settings geht es um die grundlegenden Einstellungen für die von Dataview erzeugten dynamischen Ansichten und in weiterer Folge auch um das Aufgabenmanagement, das mit Dataview ebenfalls möglich ist. Die generellen Optionen beinhalten neben Datums- und Zeitformaten auch die Einstellungen für das automatische Aktualisieren der Suchergebnisse in Tabellen, Listen und Kalenderansichten. Das setzt nämlich das Aktivieren der Option Automatic View Refreshing und eine Zeitangabe in Millisekunden unter Refresh Interval voraus. Die Option Display result count zeigt die Anzahl der Treffer für eine Suchabfrage, die in einer Tabelle oder Aufgabenliste ausgegeben wird. Wenn Warn on Empty Result aktiviert ist, bekommt man einen Hinweis, wenn eine Suchabfrage keine Treffer liefert und mit Render Null As wird eingestellt, wie dieses leere Suchergebnis dann angezeigt werden soll.

Unter Table Settings können der primäre Inhalt und die Gruppierung in den Ergebnistabellen definiert werden. Schließlich werden unter Task Settings die grundlegenden Einstellungen für das Aufgabenmanagement gesetzt. Dort sind manche Optionen erst aktiviert, wenn die Basisfunktion Automatic Task Completion Tracking aktiviert wird. Auf das Aufgabenmanagement mit Dataview wird an dieser Stelle jedoch nicht weiter eingegangen, zumal ich selbst damit keinerlei Erfahrungen habe und eine andere Methode verwende. Die Dokumentation des Plugins bietet für das Aufgabenmanagement mit Dataview jedenfalls eine erste Anlaufstelle.

Fazit & kritische Gedanken

Mit dem Dataview-Plugin erweitert man die Möglichkeiten von Obsidian um ein gutes Stück, denn durch das Betrachten des Obsidian-Vault als Datenbank, um daraus dynamische Ansichten zu erstellen, können Informationen effizienter organisiert und genutzt werden.
Es gilt jedoch zu beachten, dass die DQL-Abfragen, die man mit dem Dataview-Plugin in Tabellen, Listen und Kalenderansichten umwandeln kann, ausschließlich in Obsidian genutzt werden können, und zwar nur dann, wenn das Dataview-Plugin installiert und aktiviert ist. In einem Obsidian-Vault ohne Dataview-Plugin oder gar in einem anderen Texteditor wird man anstelle der oben gezeigten Leseliste immer nur den Quellcode der DQL-Abfragen sehen. Das gilt es insbesondere hinsichtlich der Langlebigkeit und Zukunftssicherheit der eigenen Notizen stets kritisch zu betrachten.

Wer das Plugin ausprobieren möchte, kann es entweder bei GitHub oder direkt aus dem Verzeichnis der externen Erweiterungen in Obsidian herunterladen und installieren. Und wenn man sich die ersten Gehversuche mit der DQL-Abfragesprache erleichtern will, dann sollte man einen Blich auf den Basic Dataview Query Builder werfen. Mit dem Basic Dataview Query Builder kann man Dataview-Abfragen generieren und diese dann in Obsidian verwenden. Das Werkzeug, das im Browser läuft, ist selbst kein Plugin und soll vor allem Anfänger dabei unterstützen, erste Abfragen für das mächtige Dataview-Plugin zu erstellen und sich so mit der Syntax von DQL besser vertraut zu machen. Eine durchaus praktische Hilfe, deren Ergebnisse auch gut als Ausgangspunkt für die Verfeinerung von fortgeschrittenen Suchabfragen genutzt werden können.

Abschließend sei noch darauf hingewiesen, dass auf der Roadmap zur Weiterentwicklung von Obsidian derzeit in der Rubrik Planned noch die Funktion Dynamic views steht, die das Erstellen dynamischer Tabellen aus den in den Properties der Notizen gespeicherten Daten ermöglichen soll. Das klingt nach einem ähnlichen Teil des Funktionsumfangs aus dem Dataview-Plugin. Wie das genau aussehen wird und wann mit dieser Funktion gerechnet werden darf, ist derzeit noch nicht bekannt.