the structure: block - tag - page, can offer layers of information, some small word can stay in a block, some big words can grow into a page, thus can build up something bigger, something normal, like a single building vs a community.
and a community offers the convenience of biggness … the similar blocks can stay together easily.
and also in concern of connectivity of blocks, if we say all blocks in journal pages to be tagged, those blocks in a page will not have to all tagged, as they are under the same roof ( tag, page), they enjoy a sense of connectivity by default, and some of them are free of tags, this is also mind of efficiency of tags.
if every thing flattened into blocks, at the same level, then all of them have to be tagged, and sometimes, a cluster of blocks have to share the same tags, if conjure them together into a bigger block, then the block is another form of page (in the shape of block), and might it be messy as well.
That’s a good reasoning, @baiwj . But, as @BBob will say again and again, the same thing could be done with blocks-only. Is as easy as create yourself that special blocks (the communities) using uppercase letters, for example. Or an emoji at the start of the block.
The initial proposal of this topic is asking for simplicity and freedom.
The actual structure (pages-blocks) is fine. But the all-blocks in a DB version is even better because is more flexible. And it’s proved again and again by succesful outliners like Workflowy or Tana.
None of them use references to tag blocks and their children, right? To my knowledge only Roam Research and Logseq do and they both have the concept of pages.
Anyway, wouldn’t it be better if we had the following option to treat specific blocks as pages?
It seems the team is considering narrowing the gap between pages and blocks. Adding here because this might be relevant to others interested in this thread.
Hope to remove page concept ! I think there is no need to maintain page concept anymore, especially when you query something, you should choose filter page or block or both, which introduce unnecessary operation. after eliminate page concept , refernce syntax and query elements is clear, simple, just like Tana…
Pages is prehistoric extinct feature that should be buried together with bad performance and laggines. The proper and effortless way of moving on a graph is blocks. And for those who don’t need any changes, it could be as simple as #page tags, without changing any workflow.
To completely feel the ease of block usage, you could try Remnote. Still open source spirit of Logseq is by far superior over other benefits that Remnote gives. Thus building a second brain that relay on your own possibilities to connect your ideas in “block like” manner will be great advantage over “page-block” approach.
I wonder once the Database Version (yeah, we all know there is a lot of work ongoing and it is nothing for the short-mid term) where the “page” ends up as an artifact. Could everything become a “block” since they have their own UID? This conversation between @Dario_DS and @Bas_Grolleman is epic one on that regard and other cool stuff, so check it out https://youtu.be/vp8tSQ5r_l4?si=DhyWQlxdVev5xdQc&t=1988
I used to say “a page is a block with a name and it can be referenced with [[name]]”. This is still true with the DB version. Indeed as I said it’s the reference by name mechanism that leads to pages, not those being saved as Markdown/Org files. So I don’t see what people mean by saying merging pages and blocks. If they mean no more Markdown/Org files, this is the case with the DB version.
Instead in Tana there is no reference by name: you reference a node by searching for it in a dropdown menu. And I guess that node needs to exist before being referenced. Instead with Logseq’s reference by name you create the reference and a new page is created.
If you consider the concept of “Information Container” and as such, you add an ID to propperly identify it, then Page and Block could be the same or almost the same. Block ID vs Page ID (Page Name). In Tana the motto is “everything is a Node” (Logseq’s block), therefore any Node (Block) become a Page (Information Container) of other nested nodes.
Indeed, the existence of that Information Container as a file or not is just a media matter (fille-based or not).
How much legacy the new DB version will afford to keep the Markdown file-based structure alive?
Forget about Logseq using files as persistent storage, it is irrelevant. Just think of the syntax that is meant to be copy-pastable around… that syntax is mostly Markdown but it also has [[wikilinks]] and #hashtags to make references. That syntax works cross-graph and potentially cross-app. It means “I am referencing [[Foo]] or #Foo” whatever they are. For Logseq those are containers of indented blocks, for Obsidian they are Markdown files in a folder in the filesystem. Maybe when you copy a reference from an app to another one, the target of that reference has yet to be created in the new app but no problem, the reference will be solved somehow.
So it’s not about files vs databases, it’s about a syntax that does similar things in different apps or instances of apps. Just like we do with headers, tables, bold, italics etc we think it is useful to have syntax for “relative” references (as opposed to absolute references like URLs or IDs).
A block is created in the root of the graph. It can even be called a “Page” type block (Remnote does this - a root block is called a “Document”. It’s still just a block, as everything’s a block).
@BBob I also see “Page” as a particular type of block with different system features.
Regarding file-based storage, @alex0, I am not sure that is so irrelevant at this moment, considering the number of users relying on the “file” concept stored locally using the MD. But your point about focusing on syntax is a good one, as long as we don’t relate that conversation with the DB movement. The fact that some apps use Wikilinks, others use MD links, and others use internal proprietary ones could be considered a lack of consistent standardisation, therefore an interoperability issue. And this is now, without any DB scenario in use.
I meant that it is irrelevant for this discussion if files or a DB are used as persistent storage. People seem to think the concept of pages came from files, instead they came from references using names.
The concepts are the same, just different names and slight variations in behavior. Remnote has “Documents” which are pages in Logseq. Rems are blocks in Logseq. Far as creating linked references, you can still link to either a Rem or a Document just as you do a block or page in losgeq but in remnote its all tied into a single function that uses double [[ to start the process. Rem’s can also be turned into Documents by specifying the Rem as a Document, logseq does not have a native feature to do this. Documents that are independent, meaning they are the root of the page, can be dragged and moved into other Documents which will absorb that Document into the parent Document, but once they are absorbed into another Document, they are no longer a separate entity. This simplifies the structure to reduce the system from feeling cluttered.
The real benefit, for me, with Remnote over Logseq, is it does not rely on local files or having to parse local files, so performance is very good and its quick and snappy. I can build out my entire knowledge graph in a single Document where Logseq would choke and die if I tried to do even a 1/4 of what I put into the Document. Remnote also has safe guards to prevent the accidental deletion of a Rem when other Rem’s are linked to it.
The DB version of logseq however could solve some of these issues… We’ll have to see how it pans out.
