We are not introducing specific properties.
Instead of reasoning in terms of Set Theory, if you look at this from the geometric point of view it will be much simpler:
-
A graph is the most generic structure. The others, like trees, are contained in it. You can extract many trees from the same graph using different indications.
-
Properties specify what kind of relation there is between nodes while a normal reference in Logseq is the default “neutral” relations.
Imagine a graph where all the connections are the same. That is a graph made from references only.
Then imagine a graph where there are different kinds of connection, each with a different color. That is a graph enriched with properties. Each property key has its color.
Now imagine to traverse the graph following a certain color, obtaining different structures including trees.
I’m proposing that the user can choose any of the property he used to extract a structure.
It’s up tp the user to dedicate one or more property keys to build a certain structure.
For example an user could introduce property keys like these:
category::for example [[Mechanics]] has the propertycategory:: [[Physics]], [[Tension]] hascategory:: [[Mechanics]]etc to get a treenext::for example [[Chapter 1]] hasnext:: [[Chapter 2]]to get a chaininstance-of::,belongs-to::etc for other trees.
Logseq doesn’t have to choose any property keys, they would be user-defined. What’s Logseq has to introduce is a syntax like {{tree key}} to traverse the graph using key as indication and display the results as a tree.
If this is clear now, please read again my previous message.