This is the second part of an article on an information first approach to Obsidian. The original can be read here.
Analyzing and Synthesizing Information
Let me state my goal plainly: I want to be able to find all of my relevant information on a given topic and synthesize my understanding of that topic in a document or drawing, maybe for personal use, maybe for sharing or publishing.
For this purpose, a primary tool I use is Graph View. Yes, Graph View. And, in the process, I rehabilitate file names as a Valuable Thing.
To explain why Graph View is the best tool for this type of work, I need to re-visit the idea of Obsidian as a database.
SQL and NoSQL Databases
There are two different types of databases. Most common are relational databases, or SQL databases. These are table-based (think spreadsheets) and depend on pre-defining relationships and hierarchies between tables. But Obsidian is clearly not an SQL database, since it has no underlying table structure. It is, in fact, a NoSQL database, aka non-relational database.
The Substack Helper thought my detailed explanation too long for this article, so I moved most of the discussion to Part 3. I encourage you to read that before continuing, but it is not actually necessary.
TLDR: Since Obsidian is a non-relational database, I use it as such.
Databases are queried for information. We have search filters that we can use for that, and which can be applied to both graphs and searches. We don’t get information from a database by opening a table or navigating to a record in the database. That is effectively the approach you take if you open a note to get its information.
Filenames revisited
In the first part, I talked about a workflow which created files with unique, meaningless names. If you have tried the proposed workflow, however, you will already have a number of meaningfully named notes in your vault. Every note has a topic::
field, which is a link or links, and those linked files have the name of the topic. The file may or may not actually exist. For Graph View, it doesn’t matter. You may have added links to the related::
field as well, thereby creating more meaningfully name notes. In the course of processing your atomic notes, you have given them meaningful names. Now that we are getting visual, meaningful names are useful. All your MOCs, existing or not, are already meaningfully named.
Graph View
The most frequent type of comment I see about Graph View is along the lines of “it’s pretty to look at, but when you have a lot of notes it just becomes a useless, chaotic mess”. That’s like complaining that a dataview query listing every note in your vault is just too overwhelming to deal with. Well, yeah! Other than when you are enjoying the eye candy, you would never look at an unfiltered graph any more than use an unfiltered query.
As described in part one, filters can be just as sophisticated as dataview queries, and graph filters works exactly like filters do in Search. So, if I want to explore the information I have relating to a topic, I start by typing the topic in the graph filter. Now I can see all the files containing the words of the topic, any of which are potentially related. Some may already be linked, but if I show orphans, I can see more files which could or should be linked to the topic. With Hover Editor, it’s easy to look at each document’s contents and decided whether they should be related or not without opening the file. And if they should be, I can add the link directly in Hover Editor. I never need to actually open any files. And I can add or remove words to my filter to find information that is related but perhaps worded differently. Finally, I can bookmark the graph and easily return to it later to discover new, related information using the same filters.
Assuming I have already created notes on a topic, I will already have a map of content named after the topic. If the file doesn’t yet exist, I can click on the node to create it and manually add the standard template. This Map of Content will already have a list of related files and a graph view which shows them, both accessible in the right sidebar. Now, as I look at potentially relevant notes in Graph View and add links to the topic::
field, my MOC is accumulating the links, and a neural network is developing.
The right sidebar version of the graph provides an additional feature, the ability to adjust “levels”. This allows you to not only see notes linked to the current note, but also notes that are linked to those notes. In a family tree this is kind of like cousins, cousins once-removed, and so forth. Some of these more distant relations should/could be directly linked to the main topic.
And remember, thanks to Hover Editor, I never have to open a file except when I create one.
Knowledge Trees
Honestly, sometimes my brain just wants a list of things without extra visual stimulation. With Bookmarks, I can build knowledge trees for a topic, basically like a rich outline.
I create a virtual (bookmark) directory for the topic. As I work with my information, I bookmark interesting blocks with information (I do not bookmark files, just information). These could be sections, paragraphs, images, embedded PDFs…anything really. Bookmarks can be named as well. For complex topics, I can create subdirectories as appropriate.
This results in what is essentially a detailed outline of all my information on a topic. A virtual Map of Content, if you will.
Synthesis
After all of this, I am ready to write. I have a blank or bare-bones file on a topic I am interested in and about which I have accumulated a bunch of information. While the note may have no content yet, apart from the standard template, all the related information in my vault is ready and available visually in graphs as well as being outlined in my Bookmarks tab. In developing my ideas, I can apply or modify filters to any of these views if necessary. As I write, thanks again to Hover Editor, I don’t need to open any files to access (or even modify) the information in them. I can stay in my document, stay in my head, and not break my thought process.
The Elephant in the Room
More advanced users often use the Excalibrain plugin to visualize their vault. It is useful if you are thinking in terms of files and ontological relationships between them. I love the Excalidraw plugin and use it a lot for visual mocs. I had really hoped that I would like Excalibrain, too. But, for my process, it is inferior in a number of ways to Graph View.
Graph View allows me to easily discover and interact with notes that are not yet linked to my topic. I can see orphans and adjust my filter, asking my questions in different ways, adding and removing search terms to reveal more potential relevant information.
Visually, Excalibrain is blocky and static. Graph view is multi-form and dynamic. From a visual perspective, this is obviously personal preference. But the dynamism of Graph View is very useful and for me makes it superior.
As new notes are linked, all the nodes adjust to fit them in place, kind of like in your brain, in which new information shifts your thought patterns. Dragging nodes and changing force levels can emphasize relationships, and I can achieve elegant visual representations of my information this way. Notes can be visually grouped using colors, which is useful for complex topics with multiple sub-topics. The relative size of nodes indicates the information density of a note, suggesting other topics or sub-topics which could be developed. I find all of this useful.
In short, Graph View is fluid and flexible. Just the way I like my thinking.
Closing Thoughts
The approaches I’ve outlined allow me to focus almost entirely on my information and not my files. I obviously need to open files when I create them, or when working on a Map of Content or Production Note, but when exploring my information I don’t waste any physical or thinking time and energy on them.
If you’ve made it this far, thank you very much for reading. These are my first articles on SubStack, and I look forward to feedback. Constructive Criticism is Always Welcome.