I’m currently refactoring some of my Logseq pages for more consistent query use and with an eye toward potential migration to the DB version in the future. I’d love your input on a structural question that I’m a bit unsure about.
Back when I was using Roam, nesting blocks under a property (like a metadata block) had functional advantages due to inheritance — tags or attributes from a parent block would cascade down. From what I understand, Logseq handles inheritance differently (or not at all?), so I’m wondering whether nesting is still a best practice — or just visual preference.
Is flat structure + page properties preferable for future-proofing, advanced queries and linked reference filtering?
Is it still advisable to nest notes under blocks like [[$Reference Note]] instead of tagging them? It feels unfeasible to manually add tags:: [[Reference Note]] to every single one.
How do you balance structure, ease of capture, and queryability in your own setup?
When two or more siblings (or cousins) contain the same (soft) reference, feel free to move their shared reference to their nearest common ancestor, no matter if it is a block or a page.
This is good structure and fully queryable.
No need for inheritance, just recursion.
Unless the reference is inline (or hard), in which case it is better to stay in its natural place.
But both your approaches do that.
There is hardly any difference between the two.
Or maybe I don’t understand the question myself.
Could indeed be a misunderstanding on what is top-level, nesting etc.
In Logseq DB, everything is a node, so the term “top-level” is merely a convention.
Even in Logseq MD, though pages are top-level, they are treated by queries almost identically to blocks.
Re (2): Got it — page properties and block properties are treated almost the same, and a “flat” page structure is technically just blocks nested under the page node. So in practice, the difference between my two approaches seems to come down to whether I prefer working with page properties or block-level structure. Does that sound right?
Re (1): Just to check I understood —
Blocks nested under something like [[$Fleeting Note]] are still fully queryable — but it requires using recursive logic in advanced queries, correct?
Inline or hard tags will be found directly also by simple queries
New DB “supertags” are likely to be used inline, I suppose ? (Nesting children under a supertag doesn’t turn the children into supertags themselves ?)
Excellent question. My best practice is nesting under metadata block.
I did it for the following reason:
Book 1
author:: John Doe
Quote #tag1
If i then went to the tag1 page, there was the quote, of course under linked references, but no filter option for John Doe.
If i nest the quote (or for that matter any book note, fleeting note, etc.) the block property of the Book 1 block is inherentend and i can filter my linked references for that author.
Since i use this workflow a lot - going to a dedicated page and then looking to my linked or unlinked references (and eventually filtering them), this works very good for me. I use the references section more often than querying.
I have the strong feeling that this workflow is not future-proof if i want to switch to DB, but for now and for the markdown version it works fine for me.
Newbie here. I’m sorry for posting this here, but I cannot find the icon of where I can initiate a new post and I was wondering if you could help me out. I feel like an imbecile asking the question, but I legit can’t find where the icon to create a new post.
My understanding of @mentaloid was that on pages, top-level page bullets are nested under a page properties metadata block. Hence this should give the same behaviour in filters ?
–
title:: Book 1 ← page properties metadata block
author:: John Doe.
