This kind of replicates the folder/tag distinction, in that the Namespaces/Pages/Indentation manner of creating context is structural, and the Page Properties/Block Properties manner of assembling items to view is dynamic.
When using Properties, contextual information information becomes widely distributed. You tag the note to a structural idea but did not follow a browsing path to the point in the structure where you want that note.
One challenge for me here is that building out structural relationships which have some stability (e.g namespaces, folders) and are easily visualized, has great mnemonic value.
For someone like me, the up front decision of “where to put a note” is actually one of the best parts of personal info management. I love it because it’s an up-front investment in developing mental clarity. I’m a structuralist thinker.
The timeline approach confuses the hell out of me. I suppose if I was free to build out my topic-oriented graph, and timestamp entries so that they got embedded into the Journal kind of incidentally, I wouldn’t mind. I hate the idea of working in the Journal though.
If I want to work on my History of Goth Rock page, I want to work on that page, toplogically! I don’t want to work in my Journal and tag it to that page. I’d rather it was the other way around.
Once I start dispersing structural information across blocks in the form of properties, I get lost. I lose my bearing/orientation, and each note loses meaning for me. It only makes sense when I traverse a meaningful path to get there.
Even if the UX is similar, knowing that I have to add properties to a block to get it to show up in the right place, instead of just clicking a stable structure to get there, is disorienting. I lose my trust in the system that way.
tl;dr There are cognitive reasons people might prefer the Namespaces/Pages/Indentation manner of creating context, as opposed to the Properties manner.
If the two were technically combined, some of that tension would ease. If I had a Namespace page that was editable, so I could move pages up, down and around the outline on that page, and this automatically updated a Namespace property, then it would matter less to me.
Or if there was a Hierarchies page, with one root-level “Namespaces” block as a system-provided block, but then you could add Query-based hierarchies below that, this would also be a bit more usable for me.
I have a little hack where I query {{namespace [[Hierarchies]]} on the Hierarchies page itself, and then I put every single page in a graph in the Hierarchies namespace. The page names get brutally long, but at least I have the deep, narrow pathways into the heart of my graph that match the way I prefer to access information.
In Bergman and Whittaker’s book, “The Science of Managing Our Digital Stuff”, they point to research indicating how when it comes to Personal (as opposed to public) information, most people prefer navigating a structure to searching for (therefore remembering) terms.
That may be because you can use procedural memory instead of declarative/semantic memory, or you can rely on recognition instead of recall to access information. Navigational methods activate a large bilateral posterior region of the brain, much of which operates subliminally, to guide info retrieval. Search leans very heavily on Broca’s area.
So the two manners of creating hierarchy Cesar mentioned kind of map onto this navigational vs. keyword-based way of structuring knowledge.