At the corner of each note, Luhmann ascribed each note with an ordered ID, allowing him to link and jump between notes. In Org-roam, we simply use hyperlinks.
Org-roam is the slip-box, digitalized in Org-mode. Every zettel (card) is a plain-text, Org-mode file. In the same way one would maintain a paper slip-box, Org-roam makes it easy to create new zettels, pre-filling boilerplate content using a powerful templating system.
One thing with Luhmann ID system is that it gives his zettels a sequence relation. For example, the zettel 4a3 comes before 4a4 and after 4a2. So, Luhmann’s methods not only allows him to link his zettels to one another, *but also* establish some sequence relation.
In org-roam, however, by using the id: link, we are only establishing linking. The id: links themselves do not carry a sequence rule. By looking at outgoing links and incoming links (that is, “backlinks”) of a zettel, you cannot discern which of the linked zettels comes next, elaborates the current zettel’s topic more in a particular direction.
Am I correct in saying this? How do you handle continuity directions in your zettels with org-roam?
I think I can make use of ROAM_ALIASES property of nodes here. Since nodes can have more than one aliases, I can give a node a luhmann sequence value as one of its ROAM_ALIASES value:
* Artificial Intelligence
:PROPERTIES:
:ID: <UUID-VALUE-HERE>
:ROAM_ALIASES: [4a3] AI
:END:
and then, another node can have:
* OpenAI and their funding
:PROPERTIES:
:ID: <UUID-VALUE-HERE>
:ROAM_ALIASES: [4a3b]
:END:
Let’s say I am reading back my note on OpenAI and their funding node of mine. I notice that it has a ROAM_ALIASES property value [4a3b]. Then, even if the text body of the node might not have a link to the Artificial Intelligence node, I know that I can search for the ROAM_ALIASES value of [4a3a] or [4a3] and walk through the sequence like that.
Now one cool thing would be org-roam understanding these sequences as links (very mich like id: links) and maybe offer first class relation to them. But, I think I can live without it as well.
OR, instead of using ROAM_ALIASES property, I think I can make use of ROAM_REFS property:
It seems to play better with linking and backlinking functionality of org-roam (refs show up automatically on the backlinks buffer for the zettel, and also you can have multiple ref values, etc.)
Alias might be problem since each alias duplicate to its own node. Org roam lacks hierarchical structuring - let know if roam refs could be hacked to this purpose
@ChuckSneed , it’d be easier if you saw it yourself. When you use a completion package such as Ivy, Helm, and Vertico (and I assume you do), the nodes appear “veritically” – one node per line – in the minibuffer. If you have an alias for a node, an alias also occupies a line, so that’s two lines for the same node: the title and the alias.
I’d just use a tag (so that it neatly occupies a column in the minibuffer completion) or add a “Luhmann sequence ID” at the beginning of the title like “(1.a.12.f) Org-roam is a Great Tool for Note-taking”.
I do not think it has changed much since you left it (not sure exactly when, though). There has been many good updates under the hood, which may not be visible to our naked eyes – one highlight for me is the improvement in the performance when you have many (a few thousand, I think) nodes – @akashp has been instrumental in getting this done in the code, so he could comment…
debian 12 had org-roam version 2.2.2. Debian 13 now has org-roam 2.2.3. Back on version 2.2.2, I had problems with database stuff (see my post history for the threads I opened back then). I am expecting 2.2.3 plays much better now.
Can’t find anything related to database on this forum under your name. Sorry. But not sure if there has been any change to the database layer in a fundamental way…
You should just compile a version and install Emacs locally. My entire system is frozen for 6 months or more - relying on debian repos for org roam would put you in a lot of disadvantages - with manual maintenance you have the ability to patch and freeze subsystems. Unless you have specific needs to only use apt - the cost benefit calculus doesn’t align.
For hierarchical structuring - you may simply use a org file with headings implicitly encoding hierarchy - with links leading to the nodes and so on. This is the most easy way.
You might find you need to shuffle hierarchy in the future - if you hardcode then - you might find yourself in difficulty in shuffling and restructuring trivially.
Treat org roam as a digital system, where you can go to a particular place easily - whether hierarchically structured or horizontally linked to each other. The data doesn’t need permanent placing - you can contextualise.
This is also good advice. Since you use (some) headlines as nodes, this may be the easiest way.
I have my own way to achieve notes sequence away from Org-roam but this is purely to satisfy my curiosity to explore and also I am in the one-note-per-file camp (just my preference; I have no argument for or against use of headings as nodes).