Create multiple levels of hierarchy with property chains (similar to Breadcrumbs in Obsidian)

[gax]

@antintin

The reason I think elements of a category and subcategories of a category don’t need a distinction is because you can always get more specific. A page may start as an “element,” but as your required level of specificity changes, that “element” should be able to dynamically become a subcategory. With this structure, there is no distinction to begin with.

It’s the same idea as a folder-note. As you go deeper into a hierarchy, you get more and more narrow, but the subcategories (subfolders) themselves can store information, making them an element of their parent category.

@gax

They are fundamentally different things, for sets it would look like this:
Physics = {1,2,3,4,5}
Mechanics = {1,2,3} ⊂ Physics
Tension = {1} ⊂ Mechanics

So Tension = {1} is an element of Physics, and an element of Mechanics, which is a subset of Physics. If I understand your logic, you’re saying that Mechanics cannot be an element of Physics, because it’s actually the label of a subset.

But each of those set labels (Physics, Mechanics) are actually pages, and the elements of the sets are also pages. They’re the same thing

I think we are on the same page. What I meant to say is that we have 3 categories, Physics, Mechanics, Tension. The numbers are the elements of these categories, think of them as articles. So 1 is an article classified in the category Tension. Mechanics = {1,2,3} is the subcategory of the category Physics that has the articles 1,2,3 in it.
It is a subset of Physics {x ∈ Physics | x ∈ Mechanics}, but it is not an element of it. {1,2,3} ∉ {1,2,3,4,5}.

Under the hood, Logseq stores all of them as individual files, at this level they are all exactly the same thing. Didac and I were just chatting in a different thread whether this is a good idea or not, Wikipedia made the decision to use a different namespace for categories. To me it feels that it might not be a good design choice, but it is unlikely to change and I don’t really know if it is bad or not.

Where the distinction comes in in Logseq is between tags and properties. So if we tag an article with #Tension, it means, in set notation, ∈, and if we use @alex0’s idea to represent hierarchies with properties, the line “broader::Mechanics” in Tension.md means Tension ⊂ Mechanics. So Logseq can make the distinction, but it uses one namespace for all of them.

To make your case look like the Wikipedia, we would take all of the pages that don’t have any content other than properties and display them in the “Categories” section, and take all pages that have content and display them in the “Pages in Category”.
Some pages, those that have both narrower properties and content would display in both sections (or could display in a different color).
As far as I can see, this would work just fine.

One downside of this approach is that it is different from the usual tagging in Logseq, so instead of tagging an article with [[Tension]], I would have to set the property broader::Tension (meaning that Tension is a “broader” version of the article, breaking the distinction between ⊂ and ∈).
Tagging would effectively be replaced by setting properties, which have a different use case. I think they don’t yet allow inline syntax either.