I like your contrast and comparison of the two systems, and can’t speak as much to the underlying programming of the two tools. From my perspective, constructing a “type:: book” property in Logseq is an effort to make it ontological, and adding “key:: value” properties of other types can be tantamount to making attributes for objects.
So in terms of the mental processes I need to execute to design these key-value systems in Logseq, that kind of thinking feels similar to designing supertag systems in Tana. It’s the one area where using Tana feels most like “levelling up” to use properties and queries in Logseq.
I know that’s not “levelling up” Logseq use relative to where you are in your mastery of the tool, but it is for me. If I am going to struggle that much to think in this new way, Tana’s tag UX for thinking about those things helps.
I prefer many things about Logseq. I find the “page” to be a useful construct for my way of thinking, and I love its PDF annotation features. But when you consider the mental activity of constructing queries over personally-defined properties (just that functionality alone), from the perspective of a new user who has never done this before, that cognitive work is not completely different in the two tools.
I still look at my content struggling at how to make it so I can pull it together in a meaningful way, by defining types of things and the properties about them that I care about. Tana basically pushes that style of thinking in your face right from the get-go. Step 1 = define objects and properties, and searches that makes those properties meaningful.
Tana people will say you can “just start typing” like Roam/Logseq people emphasize, but that’s not really true. Their own tutorials almost always begin with “tag your node so it becomes a type of thing, then configure its properties”.
In Logeq, you can carry on for quite some time before you have to do that kind of thinking, but at a certain point, to do some of what you want to do, you end up doing the same kind of thinking about groups of objects, attributes and queries. But where Tana’s worked hard on the UX of that, Logseq gives you much less support.
From a beginner’s experience perspective, the most extreme difference besides Tana forcing structural thinking on you right away is that Logseq has Pages you can go to and edit, which is more familiar as a cognitive construct than Tana’s “everything is a node” nature, where you essentially need queries (“live searches”) to see anything cohesive on any subject.
I really don’t care where my data lives, or if there’s an relational or graph database working under the hood, or any underlying issue like that at all. Also, honestly, if its open source like Logseq, or core-team plus plugin-community like Obsidian, or the more closed-shop models like Roam or Tana, again, those don’t have an impact on my efforts to use the tool.
So the YAML front-matter and data-scoping in Obsidian, Tana supertags & Logseq properties and queries are all functionally similar enough for someone like me to call them the same “feature”, and compare how that function is implemented in each tool. And they are the same not because of any characteristic of the technology, but because of the kind of thinking they force me to do.
If I’m sitting here trying to learn Logseq, and I’ve played with Tana, and I read that I should define “This is a type:: book”, then it definitely feels experientially like Logseq’s asking me to do what Tana asks me to do, which prompts me to compare my experiences using booth tools.
Edited to add: this is why I support your Feature Request on the syntax for inline properties, @alex0 . It makes this whole process of defining objects and properties feel much more natural than in any other tool I know. It also really fits the Logseq “efficiency first” pattern you describe, of “just writing”, and quickly developing structure almost as a side-effect. So I think your improved syntax is a good idea on a few counts.
I don’t know what your day job is but I wish Logseq would make you product manager for the “properties” layer of the tool!