Namespaces make my life miserable. Are they worth it?

Well, the way it is currently written looks like it’s a journal event, so I would add it in today’s page, using the template I have for journal events.

For the query, I would search for client pages that are mentioned in a journal event entry, and contains the text “exercise plan”.
If the results weren’t good enough, then I would migrate to using properties (something like customer.has-exercise-plan).

I don’t know how complex queries are built as it seems it’s a complicated thing and it has a steep learning curve that is mostly out of reach for most non-programmers but I assume you would have a dedicated page for this person where you have, in the form of properties, the role as a customer. So the query would search all pages where the role is customer, pick the name, then search all pages or journal pages where that name is mentioned along the “exercise plan” string or property right?

If I were to use a custom property, it would be placed as a page property within the client’s page, so you would just need to query for pages where type/role is customer and that custom property is equal to what you want.

About the option using journal entries, now that I stopped to think about it, it may not be possible, or be too complex where it would require an advanced query.
Finding if a particular customer has an exercise plan would be easy, but finding ALL customers whom have an exercise plan… not so much.

Ok, trying to sink in all the info here :).

So my take is that namespaces are helpful for both top-down/hierarchical structures (the usual folder-like, organizational-chart-like and general-to-particular categorization) and contextual hierarchies (cars/Audi → suggests a namespace of car brands is the focus vs Audi/cars → which suggests the products of Audi are in the focus, specifically its car models, hence the “Contextual Hierarchy” term) and don’t need to be unidirectional (both above are useful to both categorize and provide context) as I saw them until now.

The disambiguation can be (and should be) achieved in both namespaces and tagging. If I want to disambiguate Namespaces I must first get my context right cause I can disambiguate by either movies/Moby Dick (as opposed to maybe books/Moby Dick) but the disambiguation can also be achieved by saying Moby Dick/movie if the focus is the Moby Dick namespace - which has a movie, a book, a main character, an author, etc).

As for the searchability of Namespaces as a tagging system, if you really want to be that specific with your searches, you have to know that you have actually “tagged” in a certain way ([[A/B/C]] because [[C/B/A]], [[B/A/C]], [[C/A/B]] will not bring any results). But, to make sure that you can cover all bases when designing for searchability, you should actually tag by both Tags and Namespace (ex: #Audi/cars #Audi #cars -in this example, the Namespace has the focus on Audi products and I am talking about the cars Audi makes but I also want to be able to re-surface this note when doing more general searches by #Audi for example).

To sum it up -and I’m thinking out loud here- Namespaces have a lot to them and it’s not an easy at all concept to grasp. Hierarchical Namespaces are the most common and easy to understand Namespace variation. For all the other (lenses) you have to know your Focus and build that specific cluster of Tags (namespace) with that Context in mind. If you need to disambiguate, add to your namespace as the Context requires, to the left or to the right or disambiguate with #Tags, while for Designing for Searchability use both Namespaces and Tags, againg, being mindful of the minimum amount of them that will serve your searching style considering also the free-floating words in your text that can be used in searches in conjunction with Tags and namespaces. Now talk about intentionality in writing :crazy_face:

This is my current understanding on namespaces, feel free to help me (and others) improve it :slight_smile:

I don’t think this is a good approach, for the same reasons @mentaloid mentioned. Namespaces are badly suited to express hierarchies (see Would a rich commitment to hierarchies and classification be an anathema to Logseq culture? and Knowledge Management for Tags / Tag Hierarchies for an endless discussion). Unfortunately the tooling for hierarchies via properties is still under construction.

Another reason is that if you start renaming long qualified names, there is a good chance it will completely, and silently, mess up your hierarchy set by properties. Pages will just disappear from the hierarchy and you’ll never find them again.

Typing the full namespace shouludn’t be necessary, you type “Nicole” and then you’ll get autocompletion to either “Smith/Nicole” or “Blanc/Nicole” (as @mentaloid mentioned, namespaces are not a good solution for names either, better just to use “Nicole Smith”)


I would disagree with this. In my opinion, namespaces are totally unsuitable to express hierarchical structures. My view is here: The Most Legit Use of Namespaces - #10 by gax

I think namespaces are suitable and needed for two areas:

  • To disambiguate names if one absolutely can’t find unique names.
    • Nicole Smith and Nicole Blanc: Both “Nicole Smith” and “Nicole Blanc” will be perfectly fine, unique names. Namespaces are not needed.
    • A good use is for dates, there are many Januaries, they can be kept apart.
    • Project/subproject is also a good use case.
    • To resolve conflicting requirements. An employer and a customer might require the same tag for different purposes. Corp/tag and Customer/tag can keep them apart.
  • To group pages (e.g. tags) together without establishing a hierarchy.
    • A taxonomy (e.g. animals) could live in its own namespace. This prevents contamination of a private namespace.
    • A company might prescribe their own classification scheme, this should also sit in its own namespace to distinguish private from official tags.

Hierarchies can then be expressed on top of these unique names by properties or indentation.


With all that I said I still don’t like Namespaces and I am not sold on them, they don’t seem to offer much for the complexity they introduce, in Logseq terms/way of doing things. On the other hand a namespace would be interesting as a single property if there was an easy way to change the value of that property and have all other properties in all pages and journals update (which is not possible afaik). So basically it would be just a context-providing string, allowing some elements inside to appear in different place in other such namespaces. It seems to me it would cover a lot in a quite small structure but I agree that it might end up conflicting with other properties at some point.

So instead of namespaces as a way to visualize and navigate your graph are you guys using MOCs? Maybe Indexes? Namespaces are nice because they are automatically generated, so automatic multi-parent relations would be awesome.

PS: I might have called them Hierarchies but I am not actually speaking about hierarchies per se. I also don’t have the most accurate linguistic understanding of all terms involved here. I have just borrowed it from the discussion and went along with it. If I think more of Namespaces and the way I documented Namespaces in my own language, I see them as Focus points or Focus Directions that some properties or descriptions go in a compact fashion…

Regarding Tags, I am trying to keep them in check in a Tag Legend Block that I have pinned in the Contents Tab and I refer to it very often to add more tag, merge some tags that have very similar meaning and just try to keep it tidy. Still, I have too many tags. I installed a Tag plugin but that doesn’t help. From my point of view, Tags should be mapped using AI Models and put into a separate page just like I am keeping my “Tags Legend” Block in a manual and very imperfect way.

There are also cases, where it is convenient to carry over strict hierarchies already applied in practice. For example I use a namespace to model files of my local filesystem and wire them up within Logseq:

  • /home
    • /home/daniel
      • /home/daniel/applications
  • /usr/

Another thing is called “Enumeration” in programming. That is a strict, fix set of values, that shall belong together - for example a page Project status, with subpages Project status/Active, Project status/Finished. Namespaces have the advantage, that you can either search for references of particual values like Project status/Finished, or any value within Project status, as searching for namespace parents finds children as well. (If namespaces wouldn’t provide latter, you also could just use block references).
Another example for enums is a rating system r/+1, r/+2, r/+3 etc. and all ratings are grouped up by namespace r.

I currently like to use sidebar queries with a bit of CSS customization. Sidebar looks like this with Logseq as current page:

1 Like

I started using Properties for Statuses of Projects. I feel Logseq offers several ways to organize information but at some point they fight each other or stand in each other’s way and it’s more and more difficult for the normal user to pick a painless path.

I don’t want to become an expert in taxonomies or whatever other terms get mentioned in these posts I see linked here. It all seems too complex and overwhelming. Like I said, I see Namespaces as context (direction of focus)-providing pieces of data. I kind of like to be able to navigate through them but, with the current implementation in Logseq, they are uni-dimensional and different “pages” in the namespace can’t be linked to other parents.

I know I can use MOCs and Indexes that I build myself around some direction of focus, but I wouldn’t know where to begin and I maybe need to do some more reading on it. I also don’t know if the data I am entering in the journal can be picked on and brought into different MOCS/Indexes so I can extract more value from it. I thought that that Value-Extraction from the data is done via Quries, which I haven’t gotten into either. :worried:


I agree this ways of inspecting your data should be more integrated and baked natively into Logseq. At least for me that’s currently the most flexible way I can get out of the app :confused:. It requires a bit of knowledge about queries, some linking concept you choose for the graph (I did it with page props) and awareness about the sidebar feature (!). I am sure, many users either cannot or don’t want to spend this time on customization, which is understandable.

Do you mean creating an index manually? Not sure about this one. I would see an index as being auto-created via the Linked references at the page bottom by linking blocks to this page (or queries).

Btw: What are MOCs? Edit: nvm, Map of contents I guess.

It’s even harder for me as I’ve chosen to go with Atomic Notes and Blocks, with pages being there merely for linking and for future dashboards made of queries, diagrams, places for plugins to show their results, etc. So I don’t really want properties in Pages but in Blocks and I mainly go through the Daily Journal for all my data.

I’ve been reading and its been a good discussion.
I have ended up using namespaces for two things PEOPLE and COMPANIES.
I started out using Person/John Smith and Company/Acme Works.
I have evolved to simple Pe/JohnSmith and Co/AcmeWorks ← notice not spaces and abbreviations to make typing easier.
If the person’s name immediately someone I would not recognize or there are many people with the same name then I use Pe/JohnSmith-SomethingMemerableAboutHim

I made the mistake at the beginning of trying to apply name spaces to Articles and Videos – that didn’t work, for met I found myself needing to search, and I might not have used enough tags, but seeing them in a table in chronological order as to when I accessed them, could help me find a long lost nugget. Additionally I would create a TYPE:: property for ARTICLE and VIDEO, but I have since abandoned, and simple use TAGS:: article, etc… The only problem I’ve found with this appaorach is that the query language treats propertiess as text and this means #[[TAG]], [[TAG]] #TAG, TAG, although clickable and go to the same thing, are all different items to query. Long ago I created a feature request (but have no idea if it will ever get implement)

1 Like

I couldn’t agree more that namespaces, while useful, aren’t worthwhile, and introduce a lot of compatibility and file naming issues.

I prefer using the tags:: approach, as it:

  • renders a similar hierarchy in the parent note, albeit just a single level
  • allows notes to exist in multiple hierarchies concurrently
  • constructs the graph from the bottom-up, so I don’t need to worry about structuring from the top down
  • produces more readable notes: my [[dog]] Hugo with tags is vastly better than my [[mammal/canine/dog]] Hugo
  • is great for queries
1 Like

I started to do some cleanup in my namespaces because, while it is nice to see some structure and I can re-set my bird-view from time to time, it wasn’t adding much value to the tagging system itself and was just introducing a lot of complexity. I solved most of it with Logseq’s Text Expander (Custom Commands) so for most of my important and long namespaces I use accelerators in the form of Markdown Inline Links with whatever commentaries (in the Title of the Link) I feel I need for that particular one. For example, <jodo results in [John]([[JohnDoe]] "#JohnDoe, Colleague@Company, some imp stuff about John"). The best thing about Logseq Pages is that they are easy to re-factor, so using Logseq Namespaces makes sense from that pov, albeit not without issues (you can add a namespace in between others but removing it means removing it individually from all right-side children). For everything else I use VSCode’s REGEX to re-factor.
So for now I don’t consider namespaces as adding enough value to warrant their usage (apart from some very specific use cases like Projects) and foe everything else I am using unique Tags, with the only downside of not having a way to see different birdview snapshots of what is there, something that namespaces somewhat offer (or I don’t know about any such systems besides Queries).

Don’t Namespaces ruin the Graph View experience for you guys? It’s another one that doesn’t feel right about namespaces. To be frank I believe that each WikiLink from a Namespace should be part of the Graph but not the Namespace itself. It kinda defeats the purpose of the Graph.

1 Like

I have come with one: Generate explicit hierarchy out of properties

1 Like

I also prefer a bottom-up approach, but I can’t deny that a top-down approach can be helpful sometimes.
For example, I have a namespace that has been linked to 153 times (including all members of the namespace).
If I open the root of the namespace, I will see all 153 linked references, but if I open any of the children pages, I get to see only the linked refs to that particular page and its children.

With this, if I forget exactly which subtopic I tagged something with, as long as it’s a member of this namespace, I will be able to retrieve it

In the end, you should use both approaches, bottom-up and top-down, to organize your notes. Start with bottom-up, then, once you notice you have a clear structure emerging, you refactor it into a top-down.

Just quoting someone who has been using logseq longer than I had:

I’m a big fan of bottom-up emergence, but it’s helpful to have top-down frameworks. It’s only a matter of time before you’ll be able to codify your bottom-up approaches and apply them top-down going forward. It’s another case of both-and rather than either-or.
— Dario from OneStutteringMind

Yeah but you can use markdown links or page alias to circumvent this. Also, namespaces like this don’t make sense unless you’re a veterinary, or just someone who really likes to take a lot of notes about animals.

What do you mean?

FYI you can use the Favourite Tree plugin to define hierarchies using the tags:: properties. They appear in the favourites section of the left sidebar and can be mixed with namespace hierarchy.

1 Like

I have done this kind of linking so that I link with Finally got my [bike]([[Fearless Warlock]]) fixed, attached the rack properly.

Then, the Fearless Warlock page would have backlinks to all Journal entries. I would then add #Bikes there, so that it links to all my bikes (I have more than one).

Similar approach to eg. books I read.

It’s worked for me well enough to find the stuff when needed.

I tried with namespaces but it got confusing pretty quick, so I rolled back to this kind of hierarchy.

1 Like

Why is

  • template/Logseq bad
  • template/Logseq better
  • logseq/template even better
  • logseq/template best (if there are more something/template)?

Maybe it’s a stupid question, but I can’t answer it and would like to understand.

Naming files and database fields in a meaningful way is not easy for me and I am very unsure. Despite a long search, I have not found an explanation yet. If I want to describe an item with the name, geo-coordinates and creation and modification dates, I can write
PointName, PointDescription, PointGeoX, PointGeoY, PointGeoZ, CreationDate, CreationTime, CreationEditor, ChangeDate, ChangeTime, ChangeEditor,
PointName, PointDescription, GeoXPoint, GeoYPoint, GeoZPoint, DateCreation, TimeCreation, EditorCreation, DateChange, TimeChange, EditorChange.

Which is better and why?