It’s a matter of mindset, it seems there are people who prefer efficiency over order and viceversa.
I came up with this idea thanks to a meme in the community of mathematics. The summary is that someone noticed that almost all algebraists eat corn in a certain way and analysts in another way.
To me, it seems algebraists prefer order over efficiency and analysts prefer efficiency over order.
The same seems to be true respectively for Object Oriented Programming and Funcional Programming (incidentally Logseq is a written with a FP language, Clojure).
I think the dichotomy holds also for
- Relational Databases: used by most applications to store the data. File systems can be considered as a subclass of RDB with more strict rules. We are familiar with RDB when we use applications like Excel, Access or Notion.
- Graph Databases: it’s the data structure Logseq uses internally. We generally don’t interact directly with GDBs but they are very common today: they turn data into knowledge by adding context, they power Google search algorithms, recommandation algorithms on platforms like YouTube and are used in Machine Learning.
Many discovered Logseq as an alternative to Roam and maybe they already know what’s supposed to be the mindset. Instead I didn’t know Roam, I discovered Logseq as an alternative to Obsidian.
Being used with file systems (and RDBs in general) like most people I tried to use Logseq with this mindset.
Instead the “efficiency” pursued by Logseq (and Roam) consists in just writing content in blocks without caring to “place” it somewhere: just write (maybe in the journal), use [[wikilinks]] and #tags when it makes sense and let the structure (a graph) emerge naturally. Then use powerful queries to browse your knowledge base.
Properties:: and page-properties:: adds RDB capabilities to Logseq and so you can enrich your experience with queries. But the “native” approach by Logseq is the other one. I think in the future Logseq could add UI to improve the RDB experience, but if you want to use Logseq properly I suggest you to learn both the approaches and understand when one is more convenient than the other and how to combine them in the same knowledge base.