My notes network is growing as time goes by, and it is becoming harder to find myself in it.
Sometimes I see that I do not notice notes which I should have noticed, and then I reiterate some of the thoughts.
I am using org-roam-server which is amazing and indeed helps to browse.
But I was wondering if some people have a good method of browsing their notes and make sure everything that needs to be connected is connected etc.
Most frequently method is directly searching for the notes title. This
requires the user writing concise title.
from structure notes
Once more structured notes being built, I can always start from this
point. Indeed, many Zettelkästen users report that this is the 1st
step when they need to enter their Zettelkästen. This requires you
constantly regroup or reconnect previous atomic notes.
from fuzzy search all my notes including content
This happen when I post something on the web, and later on I forget
the title of this information. The thing I know is the content. In
this case, it’s better to search thought all my content.
helm-grep-do-git-grep is what I do. Just make sure all the contents
are committed.
from my customized functions
I have some structure notes before the born of org-roam. I often
search for some ideas in org-brain even though I now mostly in org-roam. I somehow found a way to combine the search result from org-brain and org-roam.
One thing about this combination is that I can take advantage of the
headline support from org-brain. This is not possible for current org-roam. I cannot use org-roam-find-file to see the headline
information in any org-roam buffer.
With this combo, I can write down structure notes directly into
org-brain, which can reduce the number of files for org-roam in long
runs.
Great suggestions. Is there an alternative to helm-grep-do-git-grep that does not rely on git? I tried helm-org-rifle, but that only works on open files.
I had this problem when I was trying to keep a good mental model of my Semantic Synchrony graph. A surprisingly nice thing about linear (including tree-hierarchical) text that I didn’t notice until I had a knowledge graph is that there’s a natural traversal you can measure your reading progress against. That is, it’s much easier to know “I’ve read 40% of this text file” than “I’ve read 40% of this knowledge graph.” Your knowledgr-graph files are likely to reference each other in a circular manner – that’s why they have to be a graph, not a tree.
The most natural solution would be to write code that creates a topological sort of the files, based on something like Kahn’s Algorithm.
But my solution, and it’s the most common one, is to simply not know what’s in the graph very well. The guy who invented Zettelkasten said navigating his knowledge graph was (eventually, after it was quite big) like conversation – it often surprised him.