How I Take Notes with Org-roam

Jethro, **thank you!** I've been looking for a write-up just like this, and I feel so lucky to be getting it straight from you.

Awesome article! > I keep things simple by keeping my zettels file-based. While Org-mode provides the facilities for using headline hierarchy, I find that it provides little value to my note-taking, and can have an adverse effect on my thinking. Having easier access to drafts in the same file can have an adverse on your thinking?

Great article. Always wonderful to see people lay out their workflows explicitly since org is such a massive beast, and I appreciate the pragmatic explanation of how Zotero fits in. Accessibility nit: The light grey color in your code theme is [near-unreadable against white](https://color.a11y.com/ContrastPair/?bgcolor=ffffff&fgcolor=dbdbdb) for me and many others. Fixable with reader mode on my end but then I lose the good-looking bits of the rest of your color scheme. :)

>near-unreadable against white Interesting! I'm using a [classless theme](https://watercss.kognise.dev/) here because i'm too lazy to style the page myself, and the code exports are probably using my modus-operandi theme, so it looks strange on dark-mode websites. I'd probably just remove the dark-mode setting altogether.

I'm not sure what you mean by that, are you saying that you use the headline hierarchy for drafts? Can't picture how that would work.

Dude, it took a little digging to find out you were the author of org-roam. Thanks!

Hah! It's not something I want to announce but it's somewhat alluded to in the article. Hopefully keeping it down low reduces any bias while reading :)

But even on your dev site and GitHub. Come on :)

Ah ha, definitely sounds like partial dark mode support is the cause. Just for reference here's my view on Firefox with a dark theme enabled and no other style overrides: https://imgur.com/a/HYKKAvi If I change to a light theme I get black-on-white and everything looks great.

Very interrsting article, suprised to lern tht you play the guitar! Since I stumbled upon Zettelkasten and discovered Org roam, I've been thinking of developing a Zettelkasten system for music composition, but I have yet to develop one. Also this part, could be solved using transclusion: Zettels should be Encapsulated A zettel should be readable on its own, without surrounding context. As someone from a tech background, this can be unintuitive, but it’s okay to repeat yourself! If you have two notes that are related, X and Y, it’s okay to write about how Y is related to X in X, and how X is related to Y in Y.

Sorry for the confusion. I was confused by what you meant in: > Org-mode provides the facilities for using headline hierarchy ... [that] can have an adverse effect on my thinking Given the previous context of talking about node types I pictured something like: * main * reference * articles * drafts (I mistakenly thought this was one of your node types) But after re-reading it seems you were talking about: * zettels ** zettle 1 ** zettle 2 versus: $ tree zettels ├── zettel1.org └── zettel2.org If by adverse effect you mean "all zettels in one file" can feel overwhelming I can relate to that even though I don't quite understand why.

I have a lot of long notes from the courses I am taking. Would you fragment the course notes to make a set of separated and self-contained zettels? Right now I have one org file per course and I am wondering if this is the best way to keep the notes in the long run.

ah yes, I should probably make things clearer then! I released this guide in its unfinished state because I didn't think it would actually reach a point where I'd be satisfied, so I'll just continually refine it with public feedback.

I think some sort of system for musical composition would be helpful! I'm not quite there yet, but I'd imagine having a repository of musical phrases coded in lilypad, tied to any emotions or themes it brings up would be useful for songwriting. I just repeat myself because it's simpler. Sometimes the relationships have no direct inverse \[i.e. X -> Y != (Y - > X)'\] or have nuances that a transclusion cannot capture.

You could break down the org notes by chapter or concept, but like me you face the issue where Zettelkastens aren't well-designed for non-academics (researchers). The key is to break out of the linear curriculum the course provides and be able to form interesting links between the different concepts (something like page vi of [mackay's information theory book](https://www.inference.org.uk/itprnn/book.pdf)) For studying I find it's more helpful to keep in mind to: \- write notes in your own words (paraphrasing helps with reinforcing understanding), and \- use flashcards (to aid in retention)

> I released this guide in its unfinished state because I didn't think it would actually reach a point where I'd be satisfied, so I'll just continually refine it with public feedback. I *totally* understand that. I started releasing my writings recently with the same thoughts and now have a good amount of things published. Before commiting to that line of thinking I had maybe 1 every few years :D

Do not take it as polemics, org-roam is the best note tools I know in Emacs and in general in the present "sw world" (so, MANY thanks), but seeing it's start and evolution I suspect there is a bit of "mirror effect", for instance in the v1 only titles was used to select notes via `org-roam-find-file` witch makes essentially org-mode notes useless, since the most powerful basic feature of org-mode is being an effective outliner, the v2 correct the aim using headings instead. Perhaps a v3 will allow queries (free text as now + search operators for instance) :-) My point is: most people rightly call notes "bits of information", but fail to understand what that means. Most tend to think that such bits need to be organized like some famous system like the ZK, PARA, LYT etc and again fails to understand why: such systems do exists for a reason, they adapt a concept, working with bits of information, to the available tools of the day (the possible implementations of the concept). In the past small sheets of papers and drawers was the simplest and cheap tools that's why from ~1545 (Conrad Gessner "libraries of Babel" system) to Leibniz "Scrinium Literatum" (~1673-94), Paul Otlet/Henry La Fontaine "Mundaneum" (~1930-40) and Niklas Luhmann ZK all choose "the zettel+kasten concept", new methods like LYT use links in the modern sense since they are a common concept of a common modern tool: the personal computer. Most modern tools are still tied to files and folders because existing computer systems was born in the paper + filing cabinet era so their designer choose to copy such way of organizing physical storage in a virtual environment, unfortunately these days where many do not even know the existence of filing cabinet and suspended folders still reason in "file and folder" terms. An so are notes "software", instead of reasoning about the concept most people reason about some actual implementation of that and how that implementation can be improved. To make it short, IMVHO org-roam try to implement a "today trending concept" very well, improving it respect of other note tools, but without thinking about it's real power and meaning. Notes as bits of information means that the human instead of read, for instance, a history book, so someone else pre-digested and distilled knowledge, start exploring historical contents like *also* books, but also newspapers, statistical data etc, and elicit his/shes own personal history from them like "hey, there was a war between empire A and empire B, information read from a book, let's start exploring possible reasons behind it from a big set of sources". That means: - trying not to being tied to files and folder concepts, storage should be something "under the wood", instead of making easy to create files/adding headings to them; - being able to query notes, org-mode do have org-ql, it's not that comfortable to use compared for instance to notmuch/mu4e for emails, but does work, SPARQL is another popular non-Emacs and not really comfy query language and there are countless others but still something to go beyond the mere "note + links + access via search&narrow then follow links/backlinks" and making it as easy as possible; - being able to *compose* information, like transclusion, org-transclusion is a nice example, though TiddlyWiki have a IMO superior concept, instead of create countless headings and interlink them; - being able to intermix metadata and information, like using drawers to store certain meta-information for future queries and free text for the rest. Perhaps those happen in the future because a step at a time became clear they are nice to have, but IMO focusing on the concept more than on actual implementation can make things happen faster and avoid code re-write, changes for users in their notes (both very time consuming tasks)... Org-roam biggest success is IMO not much the ease of interlink org-mode text but the access UI (org-roam-node-find/Ivy): all others pre-existing tools are even more tied to files concept, org-roam makes access more "search&narrow", so more immediate, in a "I do not care about on-disk storage" manner :D

Nice article, and interesting to see that you ultimately decided to drop daily notes in favour of a single inbox, as well as totally split your GTD system from your org-roam notes workflow. I'm still using dailies for scratchy notes to keep track of kind of what I was doing, but have also gone back to moving all of my GTD stuff back to a separate system (from within emacs).

There's certainly a departure from a files/folders concept style of organization, to more free-form put-your-node-anywhere style. I still think there's a lot of value in having structure, and I'd go further and say that most of the value comes from structure: this is how we make sense of the world. Most knowledge work comes from creating this structure, or looking at structures from different perspectives. In this sense I think I'm happy with what v2 already provides. I'd much rather build the structures myself, than rely on a dump of free-form text, followed by analysis on any structure that evolves.

Thanks for replay :-) I totally agree about structure, notes are just bits of information, with structure they became information, without they are almost wasted storage; only IMVHO structure need to evolve, since anything evolve, and in many case we need different views of the same information, complex thing a simple and fixed structure can't give. In general we all start with a certain "structure"/"taxonomy" and for a little while it does work well, get extended well, but at a certain point in time it need refactor, and that's an expensive, tedious, time-consuming, hard-to-automate task... Anyway a new taxonomy replace more or less partially the old one, and the cycle restart but after a certain time even that does not scale much. Switch to a search based model made some fear about loosing information, think about the not so recent "desktop" evolution from classic menus to "dash-like search&narrow launchers" for instance. A stupid example for notes: #+title: Foo Bar invoices * 2022 :ATTACH: ...drawer_here with ID... ** January - ... Click the heading to open the invoice, here some information ..., links to relevant mails, projects, etc relative to that above linked invoice * 2021 :ATTACH: ...drawer_here with ID... * December - ... #+title: Baz Baz invoices * 2022 :ATTACH: ...drawer_here with ID... ** January - ... ... * 2021 :ATTACH: ...drawer_here with ID... * December - ... In `org-roam-node-find` meaningless "2022", "2021" appear, multiple times; they are meaningful in the "Foo Bar invoices" kasten/note but not node narrow/selection UI, of course there is `:roam_exclude: t` and for such simple case that might suffice. But you might want to access directly a certain month, so instead `:roam_aliases: "Foo Bar invoices - 2022-01 January"` might be of help, unfortunately in that case the heading title remain in the search list polluting results with meaningless information, so perhaps a new `:roam_title: "something"` that instead of adding an alias replace the heading title in the list like `:category:` for org-agenda, might pops up in the future, and again solve some of that issues. What if you want to see just all your invoices of a specific month? All in a buffer, so you can expand headings etc? Org-ql can do something, at least listing them, but do not form a new buffer for now. org-transclusion can help, but again that's a manual process not much different than interlinking notes. Perhaps org-ql will evolve adding options to output an org-mode buffer instead of an org-ql-view one, perhaps at a certain point in time org tags disappear, substituted by drawer property, more flexible since they can be key-value and org-roam might add them instead of the `#tag` mechanism of today etc. ...Well... Long story short, it's hard to foresee the future, but I believe from observation that at a certain scale the "notmuch/mu4e + counsel-notmuch/counsel-mu" search/access model appear, perhaps in an evolved org-mode (we just see few evolution to make org-mode faster with caching mechanism). I'm not intended to be arrogant or to request features that way, just observing how my notes and few others I know evolves, eliciting some patterns. Today many AFAIK do have their own collection of hacks, generally case-specific, they work well enough, but sharing such information might led to common patterns and instead of producing countless hacks a common/semi-universal solution might save tedious cycles of refactoring any few years. How to do so without falling in GNU Hurd-alike traps it's probably a bit of magic but...

Sorry for the double post, as always I tend to write too quickly, especially for my poor English, and so I produce a bit confused walls of text... Anyway, the above is an example of what I see today, but that just an example, Gnus show that scoring might be (is) needed for even bigger scale, also show unified interface concept where mails, feeds and news live in the same UI treated in the same way, just with different scoring policies to avoid missing important stuff. Foresee ALL such possible evolution probably end up in an analyze-paralyze scenario or in something like GNU Hurd a fantastic but never complete enough to be used project. However evolving following the present days needs might not be better, since demand the above refactoring cycles. The idea is: try to imaging the future is not wasted time, sure it will be different like today internet is different than Paul Otlet/Henry La Fontaine Mundaneum, the implementation differ the concept though not much. So it's possible to craft something today imaging a bigger/different outline for tomorrow and keep evolving with such idea in mind, solving problems as they appear but with them always contextualized in the "future design" and evolve it accordingly. Doing so might help a quicker evolution and avoid some refactoring since while there is no implementation of the vague future outline today development already takes into account a bit that so probably future changes will not be complex to in refactoring terms. I hope that's clearer now :-)

Thank you for the reply. That book you have suggested looks very interesting. Please feel free to suggest more if you have any that you think are worth to read. I am interested in Computer Science and AI specifically. I will try my best to internalize and adopt your two suggestions in my studying and note taking. - write notes in your own words (paraphrasing helps with reinforcing understanding), and - use flashcards (to aid in retention) Last but not least, thank you very much for org-roam. I use it every day.

It would be nice if you added a rss link. Love org roam! Thank you.

It's not a blog post but just a standalone post in its own repo, so there isn't much point haha

There is no rss link in your blog too. : / Literally started reading getting things done today after reading your older posts. I already read " How to take smart notes" and I think it can really change your life. Absolutely love your work!

My blog does have an rss feed: https://blog.jethro.dev/index.xml

I don't have much time to go through this in detail, but what you want is entirely possible already in Org-roam. The TL;DR is that everything in the PROPERTIES drawer is cached, and you can define arbitrary properties on nodes, so technically you can store more meta (e.g. alt titles) within the PROPERTIES drawer, and use them instead of the default title, it shouldn't be hard to write something. I'd caution against storing all information in org-roam (e.g. I don't think invoices should be part of the system), but you're free to extend Org-roam however you like :)

Well, actually I've store nearly all my files in org-mode, before "manually" (with hacky small dedicated automation per kind of file) with linkmarks [1] and after with org-roam, the reason is simple: I do not want to traverse a hierarchy to reach anything. It's far faster typing few chars (like the start of my carrier/ISP/* name), hit tab/enter and find a proper note where I see all-at-once, ordered, with all relevant information at a glance instead of going down paths like ~/docs/utility/$name/$year/billNumberOrSimilar.pdf + reading eventual separated notes why a specific bill is missing or have an unusual due amount. The same is typing few chars of someone name, enter/tab and have he's/she's dedicated note with a single clickable links to a relevant mail search, eventual relevant threads equally linked, projects we might have together etc all in one place. The same apply more or less for anything else I collect, including my Emacs and NixOS configs... With Emacs/org-mode almost *anything* can be integrated, also in UI terms, and with linkmarks/org-roam/* access such information can happen "directly" or "almost directly" via search&narrow. No more curated home taxonomies to maintain, no more separate apps for anything, no more symlinks/hardlinks/TMUS-fuse mounted views of my data etc. I already have my own personal "Google search" and "GSuite" (on-steroid) locally. Only it's a bit of a pile of hacks and while similar to others peoples I know (iow some patterns are common) it's still unusable outside my own context, like a specific script to extract attachments from specific mail by an ISP and properly archiving it on org-mode. A generic solution that implement in a clean and consistent way such hacks probably can benefit others in general. I've already (ab)use org-ql to elicit some specific views of my notes, for instance to track things any new headings do have a timestamp and I have a TimeLine note with queries (links) to specific timeslice (year, month, week), with that I can see at a glance a weekly/monthly/yearly recap, in a broad way, not just how many tasks I've marked done on-time, how many retarded etc, and decide better "life" strategies for the future. Sometimes some trends emerge, then I start to collect them in a heading and follow their development, again that's help sometimes my prediction/perception capability and it's cheap enough in time/effort terms to be done. Most modern PIM/PKM/insights tools works well enough to spot "current" things, but miserably fails for long-term/mid-term stuff, with such "summary views" and TimeLine/EventLines notes such trends emerge far better. unfortunately I do not know much how to craft such system in a generic way someone else can "try himself", I've spotted some patterns, not much more than that. [1] https://github.com/dustinlacewell/linkmarks/