Yes, I understand your concern, but it’s based on a misunderstanding on your end. You said:
If you have an identical title:: key on two blocks, should one of them be removed entirely from its tree and pasted into another? I don’t think that would work very well.
In my proposal I specified that values of title:: have not to be unique, because they are not used to identify a block. A block is still identified and referenced only by its ID. What I am asking is that the title:: value is used as a label only when displaying the block in the graph view and when rendering its references (via ID).
When you say:
No, it doesn’t happen, nothing happens when giving to a block the same title:: value of a page, because that block is identified by its ID only.
I have discussed this widely in a thread called “unify block and pages”.
Pages are nodes. I’m asking to be able to turn certain blocks into nodes too without creating other pages/files to store them, but keeping them in their context, just it.
Not only the graph view piece: block references don’t work as good as page references in queries.
Basically the purpose is the same of my later proposal of aliases for blocks that we discussed on Discord and maybe that is a better approach.
For me it’s very important not to be forced to create a page (and a file) for everything that I want to 1. appear on graph view and more importantly 2. be used in queries.
I easily end up with tons of files that just have some page properties referencing other pages for the purpose of meaningful queries. Why shouldn’t I be able to define those inside a single file instead?
For example let’s say I want to look for all the books by Italian authors, currently I need at least this structure:
Books.md
- I promessi sposi
author:: [[Alessandro Manzoni]]
- ...
Alessandro Manzoni.md
- nationality:: [[Italy]]
and so on with a page for each author.
@antintin The idea of having different block types is interesting, had similar thoughts before.
Note, a page currently can have content as well, which is page properties.
For example a page alias is stored in the file header without bullet point:
alias: MyAlias <-- page-only content
- adsfda
Hence I would skip distinction between root block vs. page and have two types:
blocks, that have a globally unique name / title::
“normal” blocks referenced by ID
First point implies, you can give a unique name to any block (same as page titles):
- title: My block title
Some block content
and reference this block by [[My block title]]. This is a bit more far-reaching than OP requested.
Uniqueness is enforced by application logic in the same way, pages cannot have equal names.
It would also be cool to have a third type of block “browseable blocks”:
But what would be saved in Markdown files? [[id]] like [[12345-12345-12345]]?
So I would have blocks like:
- [[12345-12345-12345]] is a [[abcde-abcde-abcde]] written by [[vwxyz-vwxyz-vwyz]].
?
Or do you mean that references like [[Name]] are stored in Markdown files, then Logseq look for a block with title:: Name as property?
In that case, when a block is saved as its own Markdown file? When it has a title:: property? But then if there are multiple blocks with titles in a tree, what is saved to files?
Or maybe every time a block gets a title:: property it is moved to its own Markdown file together with all its children and a reference is left in its place?
Indeed, that’s why I am looking for a way promote specific blocks to “nodes” like pages.
I think I will gather the differences between block and page references and report them individually, but I would still need a way to tell Logseq “display this block in the Graph View and link it to other nodes according to references to and by it”.
Otherwise I am doomed to have many Markdown files with just page properties referencing other pages, for the sake of a meaningful Graph View.
What I don’t understand though is where these title blocks are going to be stored. You can’t just create a block on its own right now - it has to be attached to a page. That’s why I was thinking about the root block concept
Edit: oh you’re saying keep pages? Would you propose they can store more content than just properties without a block?
If the problem is the big number of files, treating some blocks as pages sounds like a hack (and it could become a bigger problem when collaborating). At the very least, it increases the confusion between pages and blocks. It then comes as no surprise that some people are willing to abandon pages altogether.
Theoretically, the number of pages should not matter, and their size should not be a criterion:
A big block is still a block, not a page.
A small page is still a page, not a block.
Multiple small pages are still pages, not blocks of another page.
The problem is not conceptual, so it should not question the conceptual distinction between pages and blocks (some explanation here). What if addressing the problem explicitly, having an option to save some pages together in the same file instead of one file per page, but otherwise treating them just like any other page? Similar to the option of hiding some pages from some views. Such options could be enabled either for a specific page or for all pages that have a specific property. In my opinion, that would be a cleaner solution.
The problem is that trees of blocks are perfect to organize objects hierarchically but those objects can’t be nodes of the graph; they can only be references to pages.
My workaround is manually compile indexes of page references (and other things) and a query in each page to see in which index it was mentioned, as showcased here:
The objects in your showcase (as well as the books and authors in your previous examples) are of the types of objects that deserve separate pages. And since an object may participate in multiple hierarchies, indices of page-references look like a natural thing to do. What is the downside in your current approach, that the requested feature would improve?
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.
