The Most Legit Use of Namespaces

Thanks for your detailed reply. I’ll check out those posts.

Your points make a lot of sense but many/most are not applicable to me: I am a home user and the only one to use Logseq. But then again …… never say never :grinning:

1 Like

This makes me think: if Logseq will get templates of properties based on tags like Tana, namespaces could be used to chain templates like Tana’s inheritance between its supertags™. For example:

- Alice #person

- Bob #person/author

- Charlie #person/actor

Looks like a good scheme to me.
These are the alternatives I could think of. Did I miss any?

  • Namespaces
    • lightweight, easy to search
    • interface of properties and namespaces could be tricky (e.g. if we also start to categorize games into a hierarchy)
  • Properties
    • ok for hierarchies, but would still need a namespace to keep all of the “Notes Session 1” pages
    • I don’t think it’s a good solution, like you said, it’s not really a taxonomy
  • Unique names like “Notes Session 1 DnD Asken”
    • not good…
  • Everything in one big page
    • might render slowly
    • interferes with normal indentation (but could use subheadings instead of indentation)
    • not as easy to navigate (but a search script might create a good index page)
  • Nested tags
    • don’t seem to be stable (I haven’t tried in a while)
    • easy to get wrong without typing
1 Like

Thanks for confirming namespaces are probably the best fit here!

Hah yeah, that would be a ridiculously big page. Not useful to navigate as you said.

You can do something like this with the powertag plugin.

I use namespace in only one scenario : months of a year. (I’m used to follow track of time with something similar to bullet journal methodology)


Year’s page will contain events of the “future”. When a new month starts, I move the bullets on the newly created month’s page.

As said in this discussion, namespace helps to make 2 pages with “same name” unique.

With this convention, I can have monthly pages of a year nicely sorted at the bottom of page 2023.
I can also use the same naming convention for months of next year, as namespace guarantees unique page name (2023/01-Jan <> 2024/01-Jan).


Lol I do the exact same thing for the exact same reason! :smiley:
Though my year page only contains year related info (like a year theme) as I’ve never really been one to use a future log.

For your interest, if you edit the format for journal pages’ names to year/month/day, you will get journal pages under namespaces automatically :slight_smile:


This sounds great, where/how is this set?

Settings > Editor > Date format (the second dropdown)

1 Like

So, in the 2nd dropdown that would be option EEE, yyyy/MM/dd: correct?

I have only tested this one, I don’t know what happens with the others:

1 Like

This works extremely well.

I’ve started naming any date related pages similarly… E.g.,

2023/07/12/Meeting with Bob
2023/07/13/Agenda for morning meet
2023/07/13/Speech notes

Going to the 2023/07 page lists all my journal pages and everything else happening/that happened that month.


I started using Namespaces in Logseq when I began using the app back in February as a way to have an overview of all my topics/pages and I have created a common root namespace (I’ve seen others use a "/My/"), then create from there (ex: /my/projects/prjectx/client1/...). I’ve learned that Namespaces can be very lengthy, sometimes 10 level deep, and using such page names inline with your text is not usable so one must use the Markdown Link Syntax to have some shorter description (ex: Had a meeting with [John]( [[/my/projects/projectx/client1/Australia/John]] )), resulting in a text that is free of long namespaces and ugly formatting (“Had a meeting with John”) . Now the text looks ok and one can infer from other elements which “John” I am talking about (the rest of the description of my meeting with John, the time - I am probably having a single John during this time-, etc and, if not convinced, can hover the Logseq-Link and the popup will shed some light on the matter. It’s not that easy when you have to share notes with non-Logseq users though, but I won’t go into that rabbit hole here.

My relationship with namespaces has fallen a bit (even if I am still using them for the bird-view they offer) in favor of doing some simple tagging that, when combined in queries, gives the results I want. If I search for “cousin” and “Germany” I will get the information I need without having a Family Tree.

PS: I wish I could do quick queries in the CTRL+K - Search menu.

I also do some form of “shortening” the long namespaces and, even though I would create the following namespace: /my/financials/investments/company/Apple, in reality a tag like #Investments@Apple can convey the same amount of information in a much shorter way.

I believe I am quite far away from understanding how to correctly and productively use namespaces and sometimes I find I make a mess of everything but reading your answers here and elsewhere is insightful.

1 Like

@futurized please check this idea:

1 Like

I use logseq mostly for journaling and knowledge management and I use namespaces quite a bit for structuring. And since I figured out that namespaces can be used in aliases, even more. That opens awesome opportunities for interconnected hierarchies…

One more reason to avoid namespaces: Generate explicit hierarchy out of properties