@antintin I do not see a conflict between your’s and @alex0’s suggestion at all, yours is a very useful addition with the only difference on how to present the leaf nodes that use #tagging. That would just be an option in the {{tree …}} command. For example, in a family tree, we might not want to show the leaf nodes.
There are a lot of ways to present this in the UI, but I unfortunately I am not very familiar with the possibilities of the UI API.
The most basic approach would be to have a query somewhere on an extra index page. The output of the query will be rendered as a tree on that page @alex0 has some ideas on his “Specify and display relations…” proposal. The only requirement would be to add a {{tree …}} command and add the ability to render that output properly, which is most likely already possible.
A navigation sidebar would also be nice. The “Knowledge Management for Tags” proposal has some other ways the tree could be rendered, including icons or faceted searches.
Good point about pages tagging other leaf nodes. I didn’t think about these. Personally, I think they should just be ignored, because otherwise the tree gets too deep and at that point we could easily run into cycles.
I made a drawing to illustrate:
We have “Tag” pages. They are pages that have a property set that points to other “Tag” pages. In this case, they point to pages that have a broader/part of topic relationship.
Tag pages are regular pages and also can have content.
“Normal” pages link to these “Tag” pages, using regular #tags.
“Normal” pages can also be tagged in other “Normal pages”, e.g. in RandomPage.md
So far, this is all conventional Logseq, but currently putting in the broader attributes isn’t helpful, as they can’t be traversed.
Our graph could be searched with the {{tree …} command for any property. Here is an example to search by broader::.
{{tree broader Physics showLeaves:True reverse:true}}
This would build the reverse tree on the broader:: attribute starting at node “Physics”. I added the option “reverse” because we have only a broader:: attribute, but start at the broadest node.
The output of the {{tree …}} command could be rendered Wikipedia-style. I have left out the nodes that tag the leaf nodes. In principle, they could also be shown, but I don’t think this makes sense. We can always click on a node and look at the backlinks.
I suspect this could be rendered in standard Logseq without any UI changes.