What if I want notes on different books on the same page indented under their authors? It’s just an example but the outliner encourages to structure notes hierarchically but then using pages you split the content around and you lose the hierarchical overview.
At the moment I have a lot of pages that contains only a query that find the index where they are mentioned so that I can go there to find the actual content, hierarchically structured.
Being able to treat some blocks as nodes for me means avoiding these empty pages and when I see a reference like [[Foo]] somewhere I can go directly to a block instead of going to a page with a query that finds the desired block.
The actual content (note) should be kept in the page of its subject (book), which is its primary context. If you want it to appear within a secondary (author’s) context (instead of just referenced), should rather embed it there, without losing the hierarchical overview (neither the ability to edit it within that context). Then the actual content would back-reference the place of embedding automatically, avoiding the manual query. At this point if I’m still not getting it, I suspect that a visual example is needed.
Imagine that you are taking notes about a lesson and at a certain point a specific subject is introduced, how do you decide if it is better to turn it into a section, for example ## Foo, or to make the page [[Foo]]? Notice that if you embed a page into another one you lose the structure of references and queries won’t show some results.
Instead imagine being able to mention [[Foo]] anywhere and it is a reference to a specific section (a block). You can do it with [Foo](((block-id))) but there are disadvantages like having to remember to use that specific label and block ID instead of just [[Foo]], it doesn’t work well with queries etc.
You can think of it like this: you can have hierarchies of blocks but not hierarchies of pages; and you can filter/search (using queries) according to page references but you can’t with block references (at least not easily).
I just want to use [[Foo]] with queries and everything else but it being a block in a hierarchy of blocks, not a page.
Should not have to decide “what is better”, but “what it is”. A section is a section and a page is a page. Foo cannot be both. A block is part of a page and a page is part of a graph. A graph doesn’t have sections, it has nodes. And a page may have sections, but may not have other pages, unless they are embedded. A section doesn’t deserve its own page. The freedom to interchange these concepts is not desirable in my opinion. I can accept the use of a section to temporarily hold a future page, but it should be a conscious delay, not a permanent interchange for supposed convenience.
Maybe the confusion comes from the word “page”, when it is perceived as the page of a book, which may have an arbitrary size and content. But Logseq pages are not the pages of a book, they are books themselves. A book can be as small as a leaflet, but it is not made up of leaflets itself. When linking, the target is either a book or a position within a book, aka a bookmark. Books have titles, while bookmarks have some kind of coordinates (paths or ids). Bookmarks are not supposed to be remembered by humans, but by the used system. A given name to a bookmark like [Foo](((block-id))) is meaningful only within some context, while books like [[Foo]] can stand on their own (their context is the knowledge domain). A book’s Table of Contents is a strict hierarchy, but the book itself is not part of another hierarchy. Someone could place a book to some shelf of a room of a building of a city of a country of a planet of a galaxy, but this hierarchy is arbitrary. A book just happens to be there, its place is not part of its nature (ideally, it should be the result of a query).
If embedding affects the queries, it would make better sense to me to support more powerful queries, able to treat embedded content as local blocks. In another thread you said:
I think it is a similar case, wanting queries to look inside embedded pages, not to demote those pages into specially treated blocks (I even suspect that this may be already possible, but for that I would need specific material). By the way, wouldn’t your suggestion mess-up your metaphor in Graphical explanation of pages, blocks and references ?
Having to decide if something will be represented by a page in a graph of pages or by a block in a hierarchy of blocks is definitely a thing…
There are tons of things to change, in a 1.5 years the only (very welcomed) improvement has been block references used as values of properties being counted as block references.
On the other hand, it seems easier for me to just redirect the user to a specific block when clicking a reference like [[Foo]] and not storing anything in Foo.md file.