Well @knowlost - first you have to do the somewhat tedious task of renaming all your files - or at least, all the ones you want to appear in your hierarchy.
You have to put them all in the same namespace, under one top-level name. I used the term “Hierarchies” for this top-level name in one sample I shared. I used the term “All Namespaces” in another. If you like the idea of Maps Of Content, you could write “MOC-Hub” as your top-level term, or “TOC” for Table of Contents, or “Index”, etc.
Then you have to go through and rename all the pages in your graph to put them under that top level name. Right now I’m working on some stuff about fiction writing. So I have ideas like Plot, Theme, Character, Arcs, and types of Arcs, for example.
I’d have to rename the pages like this (using MOC as my top-level name):
MOC/Story-Theory/Theme
MOC/Story-Theory/Arc
MOC/Story-Theory/Arc/Plot-Arc
MOC/Story-Theory/Arc/Character-Arc/Readiness-Arc
MOC/Story-Theory/Arc/Character-Arc/Damage-Arc
MOC/Story-Theory/Arc/Character-Arc/Awakening-Arc
MOC/Story-Theory/Arc/Character-Arc/Choice-Arc
It’s ugly. Every page ends up having a fully specified path as its page name. Pages are named according to their breadcrumb trail in the hierarchy you want to build. It won’t scale very far.
Anyhow, doing all that will give you an MOC page. Navigate to that page. There, you just type the following query on a line: {{namespace [[MOC]]}}. It seems like a self-referential query, because you are asking it to return all the pages beneath and including it, but then displaying it “on itself”. In truth, I think the query just returns what it returns, and doesn’t care where it’s called from.
That will give you a tree of all the pages in the MOC namespace. Then you add that page to your favourites, and you have essentially the kind of functionality I’ve been squealing about all over this forum.
You could segment your graph into several namespace-based MOCs. So you could create an MOCs page, but not use it in any namespaces.
Then you could use those God-awful breadcrumb-style page names, using several root-level names. So I could do:
Story-Theory/Theme
Story-Theory/Arc
Story-Theory/Arc/Plot-Arc
Story-Theory/Arc/Character-Arc/Readiness-Arc
Story-Theory/Arc/Character-Arc/Damage-Arc
Story-Theory/Arc/Character-Arc/Awakening-Arc
Story-Theory/Arc/Character-Arc/Choice-Arc
…and…
History/Canada/Ontario/Suburbs/Car-Culture
History/Canada/Ontario/Suburbs/Car-Culture/Canadian-Tire
History/Canada/Ontario/Southwestern-Ontario/Memoirs
History/USA/1940s/Film-Culture
History/USA/140s/Sex-and-Gender
Then on my MOC page, I could put two queries:
{{namespace [[History]]}}
…and on a separate line…
{{namespace [[Story-Theory]]}}
Then I could add the MOCs page to my Favourites like before, and there’d be a few MOCs on it
Nick Milo often says MOCs should not aspire to become exhaustive Tables of Contents. They’re just accelerators to get you into good spots in your graph. So you wouldn’t need to have breadcrumb-style page naming everywhere, just on pages you wanted to index this way.
The advantage of using a namespace-based approach is that the branch in your tree leading up to a page appears in the “Hierarchies” section at the bottom of each page.
However, a page can’t be in two namespaces at once. So my approach doesn’t allow for polyhierarchies, something @gax has written about extensively on this forum.
If we used the properties-based approach @alex0 devised, we could have polyhierarchies, but queries would have to recursively return “parent-of” and “child-of” pages based on those properties. I don’t think that’s on the Logseq development roadmap.
You can also just create an MOCs page, and hand-code the hierarchy, by making a normal outline, then putting only or mostly page names on it - but it won’t auto-update, not will it appear in the nice, salient “Hierarchies” section like the namespace approach enables.
Anyhow, the approach using the {{namespace [[ x ]]}} query is simple to execute in theory. Renaming pages by hand is a pain though.