(Idea) Org roam brain mode

[Whil-]

Now this may be a little bit out there, but the idea is worth sharing. So take this issue for what it is - a way to reach out with an idea to see if it sparks any interest..

Org brain is great as an interface to navigate between the notes library we build up. One gripe I've had with it is the need for custom properties to create links. After having delved into the Roam way of working I'm seeing a clear use case of using Org Brain as an interface to such a Roam structure, if Org Brain could utilize regular links that are built up between notes as the "brain links", instead of having custom properties.

With the two following example files:
File 1.org:

:PROPERTIES:
:ID: N1
:END:
#+TITLE: Note 1

Some content, including a link to [[id:N2]].

* Note 1, Heading 1
:PROPERTIES:
:ID: N1H1
:END:

** Note 1, Heading 1.1
:PROPERTIES:
:ID: N1H11
:END:

File 2.org:

:PROPERTIES:
:ID: N2
:END:
#+TITLE: Note 2

* Note 2, Heading 1
** Note 2, Heading 1.1
:PROPERTIES:
:ID: N2H11
:END:
Some content, including a link to [[id:N1H11]].

One can imagine that the information in these files and notes can be used to create an Org brain network. The "Brain concepts" we have are:

• Note 1
• Note 1, Heading 1
• Note 1, Heading 1.1
• Note 2
• Note 2, Heading 1.1

Brain-friend links:

• Note 1 <-> Note 2
• Note 2, Heading 1.1 <-> Note 1, Heading 1.1

Brain-parent and Brain-child are solved by the hierarchy. Child headings with an ID-property are the children. Headings or top-level file is the parent.

Ex. for Note 2

• Children: Note 2, Heading 1.1
• Parent: None

Ex. for Note 1, Heading 1

• Children: Note 1, Heading 1.1
• Parent: Note 1

This in essence is an idea to utilize the Org brain interface for navigating the notes-network that is built up with links in the Org Roam, Zettelkasten inspired way.

WDYT?

[Kungsgeten]

Ideas are always welcome! I haven't used (org)Roam myself, but I've read the book that inspired it: How to Take Smart Notes by Sönke Ahrens (which in turn describes Niklas Luhmann's note taking method, AKA Zettelkasten). After reading the book I've actually added some features to org-brain and have also modified my workflow of using it. A big upside of Roam is that the intention of how to use the software is very clear. org-brain in turn is an adaptation of The Brain, which is more open ended in how the user wants to use the tool (and I would say org-brain is even more open ended). I've been thinking about writing an article on how org-brain may be used for Zettelkasten.

Anyway, back to your suggestion! The first version of org-brain actually used links in a way similar to what you describe. The major problem was speed; searching through documents for links. While it is true that org-brain store relationships in properties, you could still use links to add these properties. Let's take your N2H11 as an example:

In the entry you write Some content, including a link to and then you use org-insert-link (bound to C-c C-l by default). Now you choose brain-friend and then Note 1, Heading 1.1. The friendship properties will be created, and the link will be inserted.

[Whil-]

Anyway, back to your suggestion! The first version of org-brain actually used links in a way similar to what you describe. The major problem was speed; searching through documents for links.

Yeah, speed is a common denominator for issues coming up around Org in general when trying to scale it up. Org roam solves it with an external SQLite DB caching information. Keeping caches up to date is an issue though.

Btw, on a related (but anyhow kind of off-topic... ;) ) note; the speed at which org-id scan's files for it's cache is significantly increased on Org mode master since some days back (19d2f79a0f) At least if you're on a windows PC. I personally had 100x speedup. Should benefit Org brain as well.

While it is true that org-brain store relationships in properties, you could still use links to add these properties. Let's take your N2H11 as an example:
In the entry you write Some content, including a link to and then you use org-insert-link (bound to C-c C-l by default). Now you choose brain-friend and then Note 1, Heading 1.1. The friendship properties will be created, and the link will be inserted.

True, if the brain properties could be automatically refreshed based on existing links and hierarchy the use case would be satisfied...! Keeping the links manually up to date is unfortunately not an option for myself. I've tried but have to declare a loss in that fight!

Would definitely be interested in your Zettelkasten / Org Brain thoughts. 👍

[Kungsgeten]

Great to hear about the speedups! Could you expand on the automatic refresh part? The links are constructed using IDs (except for file entries if I remember correctly, but hoping to change that when adding org 9.4 as a dependency). It shouldn't matter if you move or rename entries, the links and relationships should still work. You're correct however that if you delete the link, the property is still present.

The parent/child relations of headline hierarchy you describe are already a part of org-brain.

[Whil-]

Could you expand on the automatic refresh part?

What I meant was that, to my understanding, Org brain needs :BRAIN-FRIENDS: properties to keep track of friend-notes. If somehow those properties could be generated automatically from existing ID-links inside entries, then the :BRAIN_FRIENDS: could be seen as a cache that be automatically regenerated. With that it would be possible to use Org brain on an existing "Zettlekasten/Org Roam/Org Brain" system, without having to manually manage the brain links and instead use the inline links as friends.

Expanded example:
Let's say Org brain has a org-brain-rebuild-links function that does the "automatic" stuff I'm talking about. When running that on the two files in the example in the first post it would automatically clear any content in the :BRAIN_FRIENDS: properties and regenerate it according to the logic also described in the first post.

[Kungsgeten]

Sure, a way of scanning entries for links and converting them to properties would be useful. There's a command named org-brain-create-relationships-from-links but the purpose of it was to transfer from an old version of org-brain. Perhaps it needs some love :)

[michaelsjackson]

I am also interested in your thoughts about org-brain and zettelkasten, even without any article, just 3 .. 5 main points, without much explanations. Just to see if there are any hidden wisdoms. :-)

[michaelsjackson]

Wanted to try polymode quickly but somehow just got some error message, in short no success here.

[michaelsjackson]

I like the idea here, except this:

When running that on the two files in the example in the first post it would automatically clear any content in the :BRAIN_FRIENDS: properties and regenerate it according to the logic also described in the first post.

Deleting friends, would then delete also all other friends which were created manually, which you could not reconstruct from the text content / context. Maybe we need two friends then, auto_friends, generated from text content, plus the normal old friends until now. Then deletion would happen only for auto_friends. auto_friends would be only necessary for this deletion process, their functionality and treatment would be just identical.

[michaelsjackson]

In The Brain, I was considering normal links we know from WWW as friend links or jump links as they are called in The Brain. You jump elsewhere, without any extra information if the jump is in "parent" or "child" direction, which you could use for anything you wish having two poles.

However I am wishing org-brain getting one day two more linking types. add-input-link and add-output-link. Its representation would be simple: inputs coming with an arrow from left. outputs going with an arrow to the right.

input ---> current ---> output

The rest as we have now. Plus the option of converting normal links in content area, like file: links also to friend links. Maybe as mentioned above as auto-friend, to separate them clearly from what we have now.

All together we would have following, super general link types:

• parent
• child
• friend
• auto-friend (generated automatically from internal links, when an entry is visited, and only then, so this should be a slow process intentionally, so any speed problems would disappear this way.)
• input
• output

[michaelsjackson]

Having input, output separately can be useful, if you do not want to use child as input and parent as output for example, because those you use already for other organization scheme but you still want additionally input output. Thus all 4 directions from central entry would get powerful and very generally usable meanings.

From my perspective input and output are clearly at least as important as parent and child. Only because The Brain had not this concept does not mean we have to stop there as well. Here we are in emacs land, which makes org-brain open to new original useful ideas. I hope I am not the only person in universe finding this idea useful.

[michaelsjackson]

Example use case scenario for input output: Take any work which is a process. A, then B, then C.
This process you could very easily model in org-brain, just add those as input output sequence like:

A ---> B ---> C

You could travel along the process, from A to C for example. But now on C you want to dive in to more details about C, going down with child. Then in this more detailed level you can start another sequence or process or as I described very generally input and output.

If we look to one linking in detail again. Just the part between A and B:

A ---> B

I could create this same link in two ways:
(a) When I am on B as current entry. I could say: create input link from A.
(b) When I am on A as current entry. I could say: create output link to B.

It is the same link. In one case it will be represented on the left side of current entry, in the other on the right side of the current entry.

I hope some users give a few ups to this idea, now or in 5 years. Thanks friends for reading my ramblings. :-)