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
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
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
birthday::
- Bob #person/author
birthday::
books::
- Charlie #person/actor
birthday::
movies::
Looks like a good scheme to me.
These are the alternatives I could think of. Did I miss any?
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)
2023
2023/01-Jan
2023/02-Feb
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!
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
This sounds great, where/how is this set?
Settings > Editor > Date format (the second dropdown)
So, in the 2nd dropdown that would be option EEE, yyyy/MM/dd
: correct?
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.
@futurized please check this idea:
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