On Roam Research
Hello everyone! This post got pretty long-winded. This probably won't surprise those of you where were around last summer when I was a lot more active. The TL;DR is that this is essentially an article describing an implementation of zettelkasten that I've been experimenting with in Roam Research. I discuss some of the interesting features of Roam Research, and then show how I use these features to organize my notes. I also walk through an example of processing some notes into Permanent Notes.
Hopefully you find this interesting. If you've been curious about Roam Research or currently use Roam, maybe this will give you some ideas.
Introduction and Background
I haven't been as active on these forums as I once was because I have been experimenting with linked note-taking that is a lot less formalized than the zettelkasten approach. Largely, this experimentation has been due to my use of Roam Research, which makes linking between notes so flexible and easy that I didn't think that I needed to continue with the more formal categorization of "Permanent Notes" and "Structure Notes." Rather, I imagined that as long as I actively reviewed old writing and made a link whenever an association arose, I would be fine. What followed was a very fun, if very scattered 6 months. My time with this free-form approach was fruitful (160,000 words written in 6 months), but I arrived at the perhaps inevitable conclusion that this approach was not sustainable. I needed a system so that I could more easily mark which notes I expected to frequently link to versus which notes were brainstorming or free-form writing.
What I've been playing around with over the last month is an implementation of a zettelkasten workflow into Roam Research, and I thought I'd share what I've been doing. I should note at the start that a big chunk of this is inspired by Beau Haan's Roam zettelkasten. I can't find the specific video of his that I watched (his channel is here), but seeing how he implemented zettelkasten in Roam was what gave me the realization that a simple ZK backbone of permanent notes is what was missing from my approach to Roam. I do think there are some key differences in how I'm implementing this, which is why I'm writing this out rather than linking to one of his videos.
Important Features
First, a quick rundown of some of the features of Roam that I'm taking advantage of. Roam Research is a graph database that you edit using an outliner interface--think Workflowy or Dynalist. You input text into a bulleted list, and every bullet (called a "block") can be nested underneath another bullet. Essentially, every block can be the header for another set of blocks, which can be the header for another set of blocks, etc.
Key to this format is how the information is stored in the database. Nested blocks are considered a part of their parent blocks. One of the immediate consequences of this is that child-blocks take on the tags of their parents. In the above example, all of the shown blocks are considered to have the tag #[[Reading Notes]] because their parent block has that tag. Similarly, all of the shown blocks are also associated with the page [[Liebtrau2021Light]] (the difference between tags and pages is largely cosmetic, as is discussed later). The block quote shown is associated with [[PINEM]]. The two blocks at the bottom of the imagwe are associated with the page [[CL]], but the other blocks shown are not.
What you can't see in the above image is that every single block has its own ID code. This is part of what makes linking in Roam extremely flexible. Just as every block can become a parent block, every single block can be linked-to by any other block in your database. This can take the form of a typical link (i.e. underlined text), but it can also include the text of the linked block. This latter form of linking is called a block reference. The benefit of block-referencing is that the contents of a block can show up in multiple places across my database, and if I edit the original block it is also edited across the database. (You can also embed blocks inside other blocks, but I don't use this feature.)
Each block shows the number of links that point to it, and you can easily expand this number to show the context of each of those links:
In the above example, the top block is referenced one other place in my database (as the number indicates). The light-blue box nested under this block shows the context of that link. In this case, the linked text is a related question. Note that I can see the block containing the link, as well as any blocks nested underneath that block. These blocks are editable from here, too, even though they are actually stored in my February 8th daily note. If these notes were referenced elsewhere in my database, I could similarly expand the list of those links, continuing to explore deeper into my database without leaving the original focus note.
The final feature worth noting is how Roam deals with #tags and [[pages]]. As I mentioned above, the difference between these two features is only cosmetic. They both operate in the same way. If you click on a #tag or on [[bracketed text]], it takes you to a page with the title of the tag or the [[page]]. From the above image, clicking on [[ITO]] takes me to a page titled "ITO" where I note what that abbreviation stands for:
Note the text at the bottom that reads, "51 Linked References." As you maybe can guess, this is a list of all of the places where I have referenced [[ITO]] or #ITO. This is where a lot of Roam users can get into trouble, I think. It's certainly where I got myself into trouble. Backlinks are seductively easy to use. While I don't agree entirely that Backlinking Is Not Very Useful, I do think that they can be harmful if overused or used incorrectly. Where they can be useful in Roam is that they can be filtered. Here, I think it is important to remind you of the first feature that I discussed: child blocks take on the #tag and [[page]] associations of their parents (and grandparents, and great-grandparents, etc.). I can, thus, take this massive list of backlinks and filter it to show only #[[Permanent Notes]]:
and, then, only #[[Permanent Notes]] related to [[LSPR]]:
And, once again, note the little numbers to the right of each block indicating how many links point to that block. I can expand the list of links to each of these blocks, continuing to explore my database without ever leaving this page.
Zettelkasten Workflow
So how do I use these features for zettelkasten?
I have three main block-designation tags that I use to organize my workflow: #[[Reading Notes]], #[[Reference Notes]], and #[[Permanent Notes]]. If a block doesn't have one of these tags, it can be considered a sort of fleeting note since without one of these tags, it will likely disappear amongst the 10,000 blocks that I currently have (and growing!). I also mix these category tags with status and topic tags in order to make it easier to filter and find notes.
Whenever I find a paper that I think could be useful in the future, I make a note of it and create a [[cite-key]] titled page where I store relevant information related to that paper. Inside of that reference's page, I have my #[[Reference Notes]] block which houses all of the important information related to this paper, such as its citation information, a link to a copy of the paper in DevonThink, the status of the paper (#Unread, #Unprocessed, etc.), and some tags relating to the paper's topic. An example of this is shown below for the paper that is listed in the first image of this post: [[Liebtrau2021Light]]
In the above example, you can also see some of the utility of the "Linked References" section of the page. I can see here that I found this paper in my RSS feed on April 27th. More commonly, I find new papers when they are referenced by another paper that I'm reading. If that were the case here, I could see which paper I was reading that referenced this paper, as well as the context of that reference (i.e. which statement is the reference meant to confirm).
You can also see that the "Linked References" includes a block tagged as #[[Reading Notes]]. As the name implies, these are the notes that I took while I was reading the paper, which are the notes shown in the first image included in this post. These notes are unprocessed (as the #Unprocessed tag under the paper's #[[Reference Notes]] indicates), and so they are still housed under the date that I took those notes. Once I have processed reading notes, I move them to the page of the associated paper:
There are a couple things to note in the above image. First, the #[[Reading Notes]] are not nested under #[[Reference Notes]]. Rather, they are their own parent block on the reference's page. These are two separate notes that are both stored under the same [[cite-key]], but they are still separate entities. Second, because I have the date that I took the reading notes as a page reference ([[February 11th, 2021]]) on the parent block of the reading notes, these notes will still appear on that day's page.
As you can also see, I have several blocks tagged as #[[Permanent Notes]]. How I create these takes a little more explaining.
Making Permanent Notes
When I process reading notes, what I generally look for is sets of blocks that could be turned into a permanent note, or could be further revised to become a permanent note. To make this permanent note, I make a parent block with an appropriate title in that day's page. This acts as a header for the contents of the permanent note. I put the note contents nested under this header block, and then replace the relevant #[[Reading Notes]] text with a link directly to this permanent note. I specifically replace the text from the Reading Notes so that the same content doesn't appear multiple times in my database. The permanent notes consolidate the permanently useful information into a single format so that I'm not constantly having to figure out which block I should link to for a particular bit of information.
The contents of the permanent note are basically what you'd expect. The parent block acts as a title for the note. Nested blocks contain the contents of the note. I sparingly will bracket words to act as broader contexts, similarly to how you normally might use tags in a zettelkasten. Once I have a decent draft of the note contents, I will add a link to relevant #[[Reference Notes]] (at minimum, the reference I initially pulled the note from) as well as links to other relevant #[[Permanent Notes]].
For an example of this, I'll once again use my [[Liebtrau2021Light]] reading notes:
After processing, the Reading Notes look like this:
As you can see, A lot of the information that originally was stored inside the Reading Notes is now gone, replaced by links to permanent notes. There still is some information left behind, though, such as a note about the laser polarization as well as a discussion of the specific conclusions of the authors. The former is more information than I really wanted to take away at this point. Note that because this is nested under a link to the permanent note, it is easy to find this information again. The latter left-behind blocks aren't processed because I am unsure how much of these conclusions are due to the fundamentals of the techniques discussed, or due to the specific instrumentation that they use. I would need to look more into the physics behind these measurements before I made a permanent note on this subject. In a later pass of these notes, I might clean up these blocks and add some more specifics about how they arrived at their conclusion. I could turn this into a permanent note, as well as add a note discussing my misgivings about generalizing these conclusions. At this point, though, I'll leave these notes behind.
As for the permanent notes:
You can't see from this image, but these notes are housed inside the daily note for the day that I made them.
Note that any link listed as (&) is a link to another permanent note. I try to keep this consistent so I can always tell what type of note a link points to with a glance. Also, note that these permanent notes reference the #[[Reference Notes]] block rather than [[Liebtrau2021Light]]. This keeps my zettelkasten links separate from my more meta-level links. If I want to see where I, personally, have referenced the contents of a paper, I can check the links to its #[[Reference Notes]]. If I want to see where notes related to the paper (on a more contextual level) are, or other papers that have referenced that paper, then I check the [[citekey]] page instead. This isn't completely necessary, since I can easily filter links, but I still like to keep these separate.
Storing My Permanent Notes
So, how do I store these newly minted Permanent Notes?
First of all, they will of course show up on the page [[Permanent Notes]] since they are tagged as such. As is discussed at length on these forums, this un-curated list is not a great way to navigate your notes, especially as the number of your permanent notes grows. Instead, it's good to create some structure that will help with navigating your permanent notes.
The first step in doing this is to add them to my master-list. In a way, this is my folgezettel. The [[Permanent Notes]] page has a manually made link to every permanent note that I make, nested somewhat arbitrarily. Essentially, I need to put these notes somewhere, so I might as well put them nested under the most relevant note. In this case, I start a new train of permanent notes, using the "basis of electron spectroscopy" as a parent note and nesting the two techniques underneath:
This works well since I don't have many notes on similar techniques, but as I develop my notes further this will be insufficient for finding these notes again. What about when I make notes discussing these techniques as they relate to measuring a particular phenomenon? Should that note be housed under the measurement technique, or under a discussion of the phenomenon? For the purposes of this master list, it doesn't matter so long as every note is only listed once. For the purposes of finding notes again, though, I need a little more structure.
Which brings us to how I use [[pages]]. As I find that I have a string of notes that tell a particular story or detail information related to a particular topic, I make a structure note using a page. For example, currently my [[EELS]] page looks like this:
This is a pretty sparse list of notes, but now I have a place to organize any future notes I might take on the EELS technique. Note, also, that these structure notes don't have to correspond to topics that I've tagged elsewhere in my database, but one advantage of using these topic pages as structure notes is that it also gives me a list of places where I've discussed EELS elsewhere:
In the above image, I've filtered out all permanent notes discussing EELS, but I could just as easily isolate only the permanent notes. You can also see that the top block listed is one of the blocks I left behind in the Reading Notes I just processed. There are also many Reference Notes for papers relating to this topic, which I can use as a launching off point if I was looking to flesh out this page with more information on this technique.
Conclusions
Ultimately, what I love about Roam is how casually I can use it to creating interlinked notes. I can write in Roam informally, just putting thoughts down in my daily notes page without planning on processing them any further, or I can take formal notes with the intention of turning them into permanent notes. I can keep track of papers that I want to read in the future as well as papers that I have already read. I can associate my reading notes with my permanent notes and reference notes, and each of these types of notes can appear in multiple different contexts.
Before I finally end, I do want to discuss some potentially pretty big caveats. Roam Research is a web-only program that has to be accessed using a browser. The information is all stored on servers in the cloud, not on my local computer. Additionally, the service is $15 per month, which is pretty steep! I've tried some of the more future-proof alternative such as Obsidian, but none of them compare or are able to replicate this workflow as easily. So, for me, the upsides of Roam are easily worth the downsides, but I also know that there are a lot of potential deal breakers for other users of these forums.
Hopefully you've found something interesting or useful is this (way too long) post. Thanks!
ORCID: 0000-0003-2213-2533
Howdy, Stranger!
Comments
@prometheanhindsight
Thank you for that thorough and well-thought out essay on how you use Roam to implement a Zettelkasten. For various reasons (some of which you mentioned), Roam does not appeal to me, but I nevertheless enjoyed reading this post.
I definitely understand reservations about using Roam. I've tried leaving it several times due to concerns over lock-in and ownership of my notes, but every time I leave I end up back within a couple weeks. I'm hopeful that the Roam designers address some of the issues that make many nervous, such as better support for offline graphs. A more robust system for storing my files on my personal laptop would solve 90% of my uncertainty around Roam.
Thanks for taking the time to read my post!
ORCID: 0000-0003-2213-2533
Wow, thanks for the details!
I imagine a file export is hard to do in an undirected graph. There are plain text replication projects like org-roam, but I don't know how well they actually work in a file-based system. It'd take someone with your experience to judge that.
Author at Zettelkasten.de • https://christiantietze.de/
Thanks for this! I've been using Roam for almost a year, and its extremely powerful. Its what actually led me onto the Zettelkasten method. I'll have a proper read later, as I love taking a peek at other peoples workflows to see if mine can be streamlined/improved anywhere.
As a side note on this, I've recently discovered an application called Mem.ai (currently invite only), which does a similar thing to Roam (although very differently), and fit other needs that I had for an app of this type, that Roam didn't. I'm waiting to see what the pricing is like at the moment, but if anyone wants an invite to Mem.ai, I have 3 remaining.
I believe its Mac or web only currently, iOS beta is due out in the summer.
I've played around a bit with org-roam. I don't know how representative my experience with it was since I don't have a great grasp of emacs, but it felt much closer to something like The Archive than it did Roam.
Obsidian can do a lot of things that Roam can, including "block-level" references. Obsidian puts a little ID code at the end of the paragraph you are linking to, and then that ID code goes in the link: [[page^ID]]. It's a pretty slick way of doing it.
I've also been keeping an eye on Logseq and Athens Research, which are both attempts to copy Roam's major features with locally stored documents. Athens stores everything in a database, so you have ownership of your files but can't read them in plaintext. Logseq is doing it in plaintext. I haven't used them enough to really comment on them, though. They both are very early in development.
mem.ai looks interesting! Like Evernote with better collaboration and linking. What do you use it for instead of Roam?
ORCID: 0000-0003-2213-2533