logseq is currently my favorite of the recent barrage of networked knowledge base applications. I have been enjoying watching videos from OneStutteringMind, who has been sharing his helpful and interesting explorations and insights.
There is a lot of powerful, cool, functionality added to the system like templates, exposing some of the database query functionality, TODO checkboxes, and all the powerful views and rendering made available by using Markdown. But the main/primary feature/function any of these brings, for me (in comparison to all the long-established databases and filesystems), is the ease of creating connections (links). Any of this stuff could be emulated by, say, creating a bunch of symlinks on a filesystem. But just the ability to immediately/automatically link/create a new node (analogous to a filesystem directory) by just referring to it in text (using a special "[[ ]]" or "#___" syntax) pretty much is THE value-added feature for any of these systems. The rest is, more or less, nothing new, when we think about many basic organization systems.
In terms of "information organization", I think one thing that's important to realize is that information connections which appear hierarchical are just a special case of general node connectivity. That is, they are just node collections with some amount of a one to many relationship. Having indented sub-block is just another form of this special case (hierarchical) of information structure. Same with multiple values in a 'tags' property. So, I guess, I just want to note that it may be a bit of an error to ever try to find the "optimal" information structure. I think the structure will be a slave to the data structures used by the tool, and not some "universal truth". In other words, the structure of information is largely going to be merely an artifact of the underlying technology.
Namespaces are, in a way, also like this. They also have a one to many relationship to the items "in" them. I am not completely sure what the logseq team intends with this (besides creating yet another way to easily create something with a hierarchical structure).
But one way to maybe think about these is to consider how namespace are used elsewhere. Basically they are a work-around to the fact that many words or phrases don't contain enough information content to not be ambiguous. We might want to use short, simple, ways to access data and functionality. But these might clash with other data/function references with similar functionality. For example, we might want to be able, in a particular context, to simply call a simple "render()" function. But that name might clash with another function of the same name used to render something different. So we can add a namespace (maybe in the form of a class): e.g. markdown.render() vs. latex.render(). So, again, there might not be any grand design, other than wanting to have the option of using using short (relatively more ambiguous names), when in a narrow context, while also enabling unambiguous operation in a larger context.
