Namespace is a touchy topic in logseq, as it informs hierarchy and people are trying to judge its worth in a relational database.
And there are two extremes of logseq users, the namespace lovers and naysayers.
-
The first camp extensively applies namespaces for organization, similar to how they would categorize notes or tags in traditional software.
here’s a popular critique from Alex: Different ways to structure data and I agree namespace is easily abused, manually capping the potential of a relational graph. -
The naysayers have trouble justifying the use of namespace in logseq where it could be done in more flexible ways.
This quote represents this ethos:what’s the benefit of
cli-tools/catovercat (cli-tools)?(This is from @blogbourri in discord in reply to @Bader 's explanation that the namespace concept comes from programming. And Bader’s reply mentions “user preference” and the ability to see “a list of all subpages”, which I don’t think is beneficial enough for people who decided they don’t need namespace in their life.)
To these people, I’ll explain a use case where namespace definitely trumps other methods.
Let me state the conclusion first:
Namespace is mainly useful for one-click retrieval (not only of subpages, but also all backlinks).
Then lemme illustrate:
If you have indented the following blocks like this to show their hierarchy:
- [[project A]]
- [[subproject 1]]
- [[subproject 2]]
It totally works for organization (especially if you put it inside an index page or tag the parent block with #index), and it’s flexible — it allows those child pages to be under different parents elsewhere. Make no mistake, I am of the opinion “hierarchy is overrated and mostly a ‘habits die hard’ thing”.
But the benefit of namespace is this:
If one day you want to fetch all info related to project A, you need to write the following query {{query (and [[project A]] [[subproject 1]] [[subproject 2]] ) }} .
- Note that I only have 2 child links under [[project A]] in my example, but in reality there’re usually more, so the query gets stupidly long.
- It’s also setting you up for potential mistakes — if you forget a link in the query, you risk missing info.
- The simple
{{query [[project A]] }}could be used to accomplish the same task if every time you tag a block with the subproject, you also tag it with the parent project.- but it’s also stupidly tedious
- and also setting you up for mistakes because who remembers to use all related tags all the time? Not me.
So for purely hierarchical things, not using namespace is actually the more high-maintenance system.
If you use namespace, it’s just one-click. Go to [[project A]] and look down, boom, all backlinks to all its child pages are there in “Linked References”. It also allows me to filter for or filter out a child page there like any other [[link]], which is also a one-click job, much easier than if I’m not using namespace.
So when I use namespaces, it’s almost always for situations like this — for things that are strictly hierarchical (chapters of a book, subprojects that are impossible to be children of multiple projects, …) AND have a meaningful parent that I would want to see backlinks to.
Some people use namespace for very broad concepts and that I would consider abuse:
If the namespace is so broad that you wouldn’t ever want to see all backlinks to everything under it, that’s a useless namespace in my book, and the Wikipedia style of page (category) would be better if you need to disambiguate.
My setup if anyone’s curious:
I filter out all child pages by default, because the Hierarchy section is right below Linked References if I want to see backlinks to child pages, and this way I can use the backlinks to the parent page to check if anything can be tagged with more granularity.
Note that, this way, the “Linked References” is quite similar to if I’m not using namespace but independant tags, but by using namespace I preserve the ability to see the “global backlinks” by removing all filters — I could do that by deleting the hidden page property filters at the top of the page so it’s also one-step.