Die Schönheit und Klarheit liegt in den einfachen, simplen Dingen. So ist es auch bei Notizen im PKM-System, die langfristig nachhaltigen Bestand haben sollen. Und das ist eigentlich auch schon Motivation genug, um von Zeit zu Zeit nicht mit Obsidian selbst, sondern mit einem anderen Texteditor einen Blick in den eigenen Obsidian-Vault zu werfen.
Komplexe Systeme sind meistens ziemlich beeindruckend. Doch je komplexer ein System wird, umso unmöglicher wird es, dieses System langfristig zu pflegen. Obsidian bietet sich aufgrund seiner Leistungsfähigkeit geradezu an, um damit ein komplexes Notizverwaltungssystem aufzubauen. Dafür gibt es einige Beispiele, die im Internet, auf YouTube oder in den sozialen Medien bestaunt werden können und mitunter auch für Aufsehen sorgen. Solche Systeme zeigen, was alles möglich ist und mit welchen Plugins oder besonderen CSS-Elementen für das Styling man das bewerkstelligen kann.
Doch wer möchte schon mehr Arbeit in das Entwickeln und Gestalten, das Ausprobieren und Ausreizen der Möglichkeiten, oder das Erforschen neuer Plugins stecken, als in den eigentlichen Inhalt? Und welche Garantie gibt es, dass nach dem nächsten Update auch noch alles genau so funktioniert, wie davor? Diese Fragen sollte man für sich klar beantworten, bevor man das eigene PKM-System auf- oder ausbaut. Keinesfalls darf das ausschließlich nach den Gesichtspunkten erfolgen, wie man damit arbeiten möchte, sondern primär nach dem Grundsatz, was man damit erzeugen will und vor allem auch, wie langfristig man die eigenen Notizen verwenden möchte. Doch die Verlockungen sind allgegenwärtig. Täglich gibt es neue Plugins, finden sich Tipps und Tricks im Internet, auf YouTube und in sozialen Medien, wie es noch besser, noch effizienter und noch schöner sein könnte. Und rasch hat man sich ein System geschaffen, das aufwändig in seiner Wartung und Pflege, sowie hinsichtlich der Langlebigkeit der darin gespeicherten Daten zumindest eingeschränkt ist.
Formatkriterien
Damit eine langfristige Nutz- und Lesbarkeit der eigenen Notizen im PKM-System sichergestellt ist, müssen hinsichtlich des Dateiformats jedenfalls zwei Kriterien erfüllt sein:
- Zugänglichkeit: Informationen sollen in gut zugänglichen und kontrollierbaren Dateien gespeichert werden. Für Daten aus proprietären Datenbanken wie beispielsweise Apples Notizen-App trifft das nicht zu.
- Offenheit: Die Dateien sollen in offenen Formaten gespeichert werden. Reine Textdateien existieren, seit es Computer gibt. Daher ist das reine Textformat das vermutlich offenste und derzeit zugleich langlebigste Dateiformat. Proprietäre Dateiformate wie beispielsweise das ENEX-Format von Evernote können nur so lange verwendet werden, wie es Apps gibt, die dieses Dateiformat öffnen können.
Die eigenen Notizen in einem Format einzusperren, das man nicht jederzeit wiederherstellen kann, wäre also langfristig gesehen ein ziemlich schwerer Fehler. Stephan Ango, der CEO von Obsidian bringt das in einem seiner Blogbeiträge wunderbar auf den Punkt:
Wenn Du möchtest, dass Deine Notizen noch auf einem Computer aus den 2060er oder 2160er Jahren lesbar sind, halten wir es für wichtig, dass Deine Obsidian-Notizen auch auf einem Computer aus den 1960er Jahren gelesen werden können.
Gestaltungskriterium
Neben den Formatkriterien ist für die Langlebigkeit der Dateien auch ein formales Kriterium zu berücksichtigen, nämlich die Einfachheit in der Gestaltung der Notizen. Grundsätzlich gilt die Faustregel, dass je reiner der Text in einer Datei ist, umso besser wird diese Datei auch in Zukunft noch gelesen werden können. Und zwar unabhängig davon, welche App man dafür dann verwenden wird. Das hat natürlich einen Einfluss auf die Gestaltung der Dateien im PKM-System. Denn nicht jeder Editor kann beispielsweise eine Suchabfrage auswerten, die man für eine bestimmte externe Erweiterung in die Notiz eingebettet hat. Statt des Suchergebnisses bekommt man dann meist nur den Quellcode zu Gesicht.
Obsidian mit seiner großen Flexibilität und den vielfältigen Anwendungsmöglichkeiten verleitet dazu, das eigene PKM-System laufend mit neuen Funktionen und gestalterischen Feinheiten zu erweitern. Nach anfänglich teils wilden Experimenten mit Plugins, CSS-Snippets, Callouts, Suchabfragen und ähnlichen Dingen habe ich mich im Laufe der letzten Monate wieder auf einen weitgehend reduzierten Stil in meinen Notizen besonnen und verwende dafür hauptsächlich reinen Text in möglichst purem Markdown. Markdown ist deshalb zulässig, weil die Formatierungs- bzw. Auszeichnungselemente bereits vor der Konvertierung einen gut lesbaren Text ergeben und somit weder Schreib- noch Lesefluss stören. Eine in der Markdown-Syntax verfasste Textdatei sieht eben auch in ihrer Quellcode-Ansicht gut leserlich aus.
Fremdeinblicke
Um die Lesbarkeit der Dateien, die ich mit Obsidian erstelle und bearbeite, zu überprüfen, wende ich einen einfachen Trick an. Und zwar öffne ich die Dateien aus meinem Obsidian-Vault von Zeit zu Zeit auch mit einem anderen Editor. Dazu kommt bei mir MarkEdit zum Einsatz. Natürlich kann man das auch mit dem vorinstallierten Standardeditor – am Mac wäre das TextEdit – oder beispielsweise iA Writer machen. Aber egal, welchen Editor man für diese Fremdeinblicke nutzen möchte, man bekommt dadurch aufschlussreiche Informationen, wie gut es um die Einhaltung der vorgenannten Kriterien und somit auch um die Langlebigkeit der eigenen Notizen im PKM-System bestellt ist.
Öffnet man ein und dieselbe Datei neben Obsidian mit einem anderen Editor, wird sofort ersichtlich, dass sämtlicher Code für externe Erweiterungen, wie beispielsweise für Suchabfragen mit Dataview oder Tasks und spezielles CSS-Styling außerhalb von Obsidian nicht oder nicht korrekt angezeigt wird. Ja nicht einmal Obsidian selbst könnte solche spezifischen Inhalte korrekt anzeigen, wenn das Plugin eines Tages nicht mehr installiert sein sollte, oder etwas mit dem CSS-Styling schiefgeht. Sinngemäßes gilt für Links, Backlinks und Callouts. Auch damit haben andere Editoren Probleme und zeigen stattdessen nur die entsprechende Markdown-Syntax an. Ebenso problematisch sind meist Tabellen.
Während Obsidian nicht nur in der Leseansicht, sondern auch im Editiermodus spezifische Inhalte wie Callouts und Suchabfragen quasi laufend ausführt und daher vollständig darstellt, können andere Editoren das natürlich nicht bieten. Sie stellen stattdessen den puren Markdown-Code dar, den man in Obsidian so nur sieht, wenn die Quellcode-Ansicht aktiviert ist.
Fazit
Die zentrale Erkenntnis daraus ist, dass nur das reine Textformat langfristig überdauern und auch in Zukunft noch nutzbar sein wird – und zwar unabhängig von den Apps oder den Plugins, die dann verwendet werden. Denn es wäre in Illusion zu glauben, dass Obsidian ewig weiterentwickelt wird. Eines Tages wird auch diese Anwendung veraltet sein. Zwar ist nichts für die Ewigkeit, jedoch um zumindest langfristig das eigene PKM-System nutzen – also die darin gespeicherten Inhalte lesen und daran weiterschreiben – zu können, sollte man auf die drei Kriterien Zugänglichkeit, Offenheit und Einfachheit beim Auf- und Ausbau eines PKM-Systems, beim Erstellen der Notizen, sowie bei der Auswahl von Apps, Plugins und sonstigen spezifischen Inhalten besonderen Wert legen. Ich weiß zwar auch nicht, ob meine Notizen außer mir noch jemand lesen will, aber mein zukünftiges Ich in zehn bis fünfzehn Jahren ist schon Motivation genug dafür, diese drei Kriterien bereits jetzt schon entsprechend zu beherzigen.
Ich kann ihre Argumente verstehen, möchte aber auf dataview-Tabellen zur Bereicherung nicht verzichten. „Saubere“ Texte zu haben ist besonders wichtig bei reinen Texten, wie Langformaten, Grundlagentexten, sowas in der Art.
Bei mir ist es so: ich arbeite gerne mit Überblicksinhalten, die genau aus dem automatisierten Zusammenziehen von Teilen aus verschiedenen Dateien bestehen. Dass das in Obsidian so gut geht, darin liegt für mich der Reiz.
Um es konkret zu machen: ich verwende Daily Notes für alles, was an dem Tag zu tun ist (checkboxen für Aufgaben) und für Notizen aller Art, denen ich ein Schlagwort voranstelle, z.B.:
#gekauft – neue Hose gekauft bei Laden xyz für xx Euro
#zitat – Für seine Arbeit muss man Zustimmung suchen, aber niemals Beifall. (Montesquieu)
#dankbar – heute habe ich eine so lustige und nette Schaffnerin erlebt (…)
#musik #koll-th Kollege T. empfiehlt Aurora: „What happened to the Heart“?
Um hier auch einen Überblick zu bekommen, habe ich dataviewjs-Seiten angelegt, die z.B. alle Checkboxen mit Kontext in einer Tabelle anzeigen oder die so heißen, wie das entsprechende Schlagwort und in einer Tabelle alle Seite verlinkt anzeigen, in denen das Schlagwort vorkommt – und dazu auch noch den Kontext des Treffers anzeigen.
Die interne Suche kann das nur teilweise. Sie kann sie nicht mehrere Schlagwörter mit UND kombinieren und liegt mir zudem von der Optik her überhaupt nicht.
Die Dataviewjs-Tabellenseiten sind zwar nicht wirklich zukunftssicher. Sie sind aber ein „Extra“. Sie nehmen den eigentlichen Journalseiten oder auch Notizenseiten nichts weg oder beeinträchtigen sie negativ. Deswegen habe ich mich gegen eine Verschlagwortung mit inline-Fields entschieden (das würde dann NUR mit dataview funktionieren) und arbeite nun nur noch mit tags / Schlagworten, weil die komplett im Basissystem integriert sind und auch wenn die Listen mal nicht mehr funktionieren sollten, dann habe ich dennoch alles gut verschlagwortet.
(Sorry, ich konnte es nicht kürzer erklären.)
Danke für den ausführlichen Kommentar! Dafür ist die Kombination aus Schlagworten/Tags und Dataview optimal. Diese – Luhmann würde sagen – Referenznotizen die Du damit erzeugst sind ein ideales Beispiel für den Einsatz von Dataview. Soweit ich informiert bin, arbeiten die Entwickler von Obsidian auch an einer Funktion, die solche Dinge direkt und ohne zusätzliches Plugin ermöglicht. Mit ein wenig Spielerei bekommt man das zwar auch mit der internen Suche als embedded search hin, aber bei weitem nicht so übersichtlich und hübsch, wie mit Dataview.