How would others feel about adding index addresses to provide some structure to their notes? For instance, I like to organize my pages into a system similar to the Johnny Decimal system, and Niklas Luhmann used an indexing system to help branch topics into deeper and more granular notes that traversed an indexing address (13.12.01a vs 07.03.04c). I think a similar method would be great with Logseq.
My thought is to add a page-property for parent:: and related:: that takes a numerical and alphabetical identification system to associate that note to its parent topic and assign that page a new index address that gets assigned to a hidden property key address::
For example… You create a page called History and its your first page right out of the box. For the parent:: property, you select a root value to indicate its a top-level hierarchy item, and it gets assigned the next available index number of 00. You then create a 2nd page called Economy and assign it to the same root value, and it gets assigned an index value of 01. You then create a new page called Fundamental Analysis and assign the parent:: key to the Index of 01, and this page now received an index address of 01.01, and so on…
The benefits I see with this system include:
- Provide better search refining (ability to show the parents page title), along with child cards that stem underneath.
- Provide a structure for one to organize their notes without the need to manually create and maintain their own index files.
- Help easily see how new topics form and in what direction by looking at an index map (graph view automatically links these pages together to show their relationship).
- In graph view, parent link are drawn with a solid line, while a relational link are drawn with a dashed line.
Additional examples of how an index system would look:
-
03.05 where 03 is tied to the index page Science and 05 would be Nuclear Energy, you then create another index page for 07.02 where 07 is Engineering and 02 is Rocket Propulsion.
- Now say you begin taking notes on a new topic for Rocket Propulsion, and you are researching a topic about Russia’s new program to develop a spaceship using nuclear propulsion, the topic is heavily focus around the engineering behind the design of such a system, so your parent:: key is assigned to
07.02 thus creating a new index of 07.02.01, and for the relational key you add the 03.05 key.
- Then as you dig deeper into the engineering aspects of the engine, your index cards will grow to represent the deeper discussions around the topic as such ->
07.02.01a, 07.02.01b, etc…
A little mockup of how a search result could appear when you type in the index number:
Hello
Out of curiosity: Why use this numbering scheme and not a (hopefully in the future consistently and cleanly implemented) system with hierarchical pages (namespace pages)?
- Isn’t it easier to build the structure with “meaningful words” than with abstract numbers?
- Is the idea here that Logseq does the numbering automatically?
- And what advantage would a page with
03 have compared to a namespace page “Science”?
Thanks for your thoughts
Chris
Searching a namespace is not always easy, and you often have to remember the name of topics inside that namespace when searching. Not to mention a lot of results that come back are related keywords that exist in other pages which makes it difficult when you’re trying to refine your search results.
But don’t confuse in thinking that 03 would replace the page name, instead it would be prefixed to the page name itself allowing you to search by that index number if you want. So say you are searching for Science/Nuclear Energy with an index of 03.05. You could run a search query for say “index: 03.05” and get the following results:
03.05 - Nuclear Energy
03.05.01 - Nuclear rocket propulsion
03.05.01a - Why such a system should be a high concern for the people if a systemic failure should occur
See my note on using namespaces/hierarchy: Discord
I find that namespaces in actual page names can be troublesome, but if you use them as page-tags it works pretty well. So instead of trying to put the page “clojure” under “programming languages” You just create a page called clojure and tag it “programming/languages” as a page-level tag. One could also do this with numerical tags: [[03/25]] just as well. I find this combination of page tags and hierarchy works very naturally and effectively in logseq.
1 Like
Thanks for your reply.
But aren’t the disadvantages you mention only present when the system of hierarchical tags has not been implemented well?
(And I think LOGseq would have to improve a lot to support hierarchical tags in a really useful way).
Names in particular are easier to remember than numbers and a search could also be restricted to a tag (if the software supports this).
If hierarchical tags are not just a half-hearted solution but fully supported, the only difference between a number and a name is that the name is self-explanatory and the number is not.
I may not have fully understood it yet, but it seems to me that you are trying to circumvent the so far imperfect namespace pages concept with a numbering scheme.
Wouldn’t it be preferable to extend the namespace pages into a fully-fledged system of hierarchical tags? If you then still prefer numbers to names, you could also use hierarchical numbers as tags.
But aren’t the disadvantages you mention only present when the system of hierarchical tags has not been implemented well?
This is true, and the one thing you do not want to do is start implementing other systems to try and fix the poorly implemented one. If the hierarchy tagging system is fixed, and the search feature is improved, then there’s a chance it could solve the issue I am facing, but i’ll get to why I am suggesting the address number in a bit.
Names in particular are easier to remember than numbers and a search could also be restricted to a tag (if the software supports this).
This may depend on the use-case, for instance with me I deal with retaining technical knowledge, not so much forming ideas, though the information I do retain does end up helping me form ideas for problem solving in the future. Every day is information overload with the number of things I am working on, along with needing the ability to pull information quickly, and top that along with my ADHD and inability to remain focused on one thing 
. A lot of the information ends up getting thrown out by end of week when I go back and review what I have collected for the week, but the information I do end up retaining may sit in my notes for a year or longer before I find a use for it again. This leads me to the issue of remembering what keywords I stored the note under, and how I ended up down the path of testing the Johnny Decimal system.
In my testing it became pretty clear just how something like the Johnny Decimal system would be helpful for my case in being able to recall information where I have no idea what keywords I used at the time. This lead me into looking more into the Zettelkasten, and noticed Niklas Luhmann also used an index address on his cards to organize and provide some structure to the system. While we do have the linking ability, it feels chaotic, and requires a lot of manual work to maintain those links but also requires visiting each page to find your other notes. When I started prefixing these index addresses to my notes in Logseq, it seemed to really click and found it to be quite useful where I could traverse multiple topics directly from the search bar itself without having to visit any pages. Either that or the Zettelkasten is just no longer a good fit for what I need and maybe I need to consider something like Dendron.
1 Like
Thank you for the detailed answer - I think I understand it better now. I am always very curious about ideas for organising notes to improve my own system.
May I also ask out of curiosity: What would be different or better in Dendron than in Logseq?
Yeah no worries man, I am the same way, I like to know if there are aspects I am missing or over looking.
So dendron has 3 features that I’ve tested and love. 1) lookup, 2) schemas with pattern matching, and 3) hierarchies.
Here’s a link that explains all 3 Features - Dendron
1 Like
In addition here’s a blog post about why the developer chose the hierarchy system he’s implemented. It goes into great detail why the choice makes sense when dealing with information overload, and dealing with the problem of searching. It's Not You - It's Your Knowledge Base - Kevin's Garden
1 Like
