I am looking for a way to link to entries of my org-roam knowledge base from org files that do not (strictly) belong to it. In this way, I would be able to link to knowledge base concepts from notes, todo entries or bookmarks.
Then, crucially, I would like the org-roam buffer of an org-roam node to list such backlinks to outside files, preferably in a separate section, to separate them from backlinks to proper nodes. (I would like to avoid turning all outside entries into org roam nodes.)
Does anyone have something similar to this approach running? I am also grateful to hear about alternative approaches.
So far I have setup the following: My org-roam-directory points to my entire home directory, so that all org files are scanned for links, however I capture knowledge base entries only in select directories. Backlinks from outside the knowledge base work, but only if the entries have an org ID. This way, they are treated as org-roam nodes, which is something I would like to avoid.
I am curious, what is your reasoning for this wish? If I understood you correctly, you want these notes/nodes to show up in your org-roam-buffer but they should not be part of regular org-roam. Also: why do you capture knowledge base entries outside of org-roam? I keep it the other way around, long-term notes are all in org-roam, short-term writing etc is outside of it.
In my knowledge base, I keep topics like “Debian package management” (that’s in the computing section), or “Band structure” (in the work section), or “Mountainbike skills” (in the personal section). I think that it’s a good idea to limit knowledge base nodes to pretty timeless concepts of which I have developed (or would like to develop) a good understanding and which I expect to be of interest to me for a long time.
Now there are also other notes, for example bookmarks, or TODOs, or short-term notes, that in the above scheme do not belong into the knowledge base proper. Indeed, I may choose to bookmark any web page that I find noteworthy, but making each bookmark a knowledge base node on its own would introduce too much noise.
On the other hand, I think that it would be useful to link such external notes to knowledge base entries, and also, from withing the knowledge base, to be able to view the backlinks. This way, for example, I could easily oversee all my bookmarks that touch the topic “Mountainbike skills”.
I do the same. (Seems like my post above was not clear enough.)
I set the variable org-roam-directory to $HOME for technical reasons, so that I can view backlinks to notes outside of what I consider my knowledge base.
Hi @grothesque , I understand what you wish to do this way:
All Org files (notes in your knowledge base and outside of it) are in your HOME directory
HOME is your org-roam-directory
You don’t want to turn Org files into Org-roam nodes
This is because they clutter the list shown in org-roam-node-find and other Org-roam list commands
You want to link from Org files outside to nodes in the knowledge base, and show these links as backlinks
The bullet point 3 goes against the grain of Org-roam; from what I see in the source code, this would require a major changes to many places – each change could be easy, but the scope is extensive, so I’d avoid this path.
I’d suggest the following two options instead:
Use another solution such as Org-super-links to do the backlinks from outside knowledge base
If you want to stick to Org-roam, then turn outside Org files to nodes, but implement a filter to org-roam-node-find, so that you’d see only the nodes within your knowledge base directories.
[Edit: I’m assuming Org-super-links do not need Org-id for backlinks; I don’t use it. But there seem to be similar solutions that add a backlink directly when you create a link. I hope you get the general idea.]
Filtering org-roam-node-find is often talked about in this forum and outside. I think you could use the directory as the criteria for this – e.g. show the node in the list only if the file is in directory X or its subdirectory.
See the FILTER-FN as an optional argument for org-roam-node-find as an example?
(org-roam-node-find &optional OTHER-WINDOW INITIAL-INPUT FILTER-FN PRED
The filter option does not display outside backlinks in another section in org-roam-buffer – that could be considered later but requires a different implementation. I’m not sure how important this is for you – if it is really important, solution 1 could be an easier option for you.
Hi, @nobiot, thanks a lot for your detailed reply.
Indeed, this is pretty much what I’d like to have. I don’t insist that my org-roam-directory must cover my entire home directory, but
I like to separate work, personal, and computing stuff in separate top-level directories within my home dir (this way, for example, it’s simple to omit personal stuff when syncing with a work-only computer.) Since org-roam-directory may be only a single directory, I do not see much of an alternative.
I find it very handy to be able to view the backlinks to any org file, and org-roam seems to work very well for that.
I already stumbled upon org-super-links by my own, but it seems to rely on org-id’s own mechanism for following links, which means that I have to keep all my (hundreds) of org files into the variable org-id-files and org-id will search them sequentially using elisp. The database approach of org-roam seems more robust and scalable to me. Also, using two separate solutions for backlinks does not seem very elegant.
(Actually, to be honest, I have the impression that org-roam functionality is mostly the database, links & backlinks. This is perfectly fine of course. OK, there’s also some support for capturing and org-protocol, but both are well supported by vanilla orgmode already. OK, there’s also org-graph, but am I missing anything else that’s important?)
But your solution 2 sounds very interesting!
I made two simple wrapper functions, one for org-roam-node-find and one for org-roam-node-insert, that call the original functions with a custom filter:
I think this correctly captures the essence of what the author has tried to achieve with Org-roam. Here is what the short description and the commentary section of the source say:
;;; org-roam.el — A database abstraction layer for Org-mode
;; All of these functionality is powered by this layer. Hence, at its core
;; Org-roam’s primary goal is to provide a resilient dual representation of
;; what’s already available in plain text, while cached in a binary database,
;; that is cheap to maintain, easy to understand, and is as up-to-date as it
;; possibly can. For users who would like to perform arbitrary programmatic
;; queries on their Org files Org-roam also exposes an API to this database
;; abstraction layer.