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.