Namespaces make my life miserable. Are they worth it?

Questions & Help
15

With Logseq it’s easy to change, for this particular situation, from “side-gig/personal-training/customers/Nicole/personalized-plan/exercise” to “Nicole/personalized-plan/exercise”, as my main relationship with her is closer now, but, otherwise, even if she turns mayor, it shouldn’t impact my business relationship with her, so, for me, Nicole will always be a customer of my personal-training side-gig, so the whole namespace makes sense to me. If I want to check her info deeper and laterally I can check Facebook or Linked-In. For me the very annoying part is having to write a namespace every time I mention Nicole. Maybe a better option would be to have this namespace as a property, because, if I will only have this info on her dedicated Page I would lose some visibility because now I can’t query for blocks that relate to customers that I have built exercise-plans for (I don’t have the customer tag or part of a namespace in the block unless it’s a property).

I, too, heavily use Markdown inline links for almost all wikilinks because:

  1. I can write naturally my input, without tailoring it to the Logseq Page Name (I met today with [Nicole]([[Nicole/Blanc]] ));
  2. I prefer a Markdown Link then a double bracket enclosed text and
  3. If I am ever going to take my Logseq files out of Logseq I can easily replace, with a script, [[Page Name]] into Page__Name.md for the Destination in the Markdown Link;

So, for the above reasons it makes sense to use properties in blocks and in those properties there should be tags or namespaces that make that block easily discoverable via multiple relations. This is congruent with the theory that you write your notes with retrievability in mind (“how will your future self search for this important piece of information?”). Moreover, I believe that tagging should be done more automatically and some properties would be recognized and added to the block as I type, With my example which I want to write as freely as possible :

I met today with Nicole to hand her the exercise plan I built for her.

When I type the word “I met” Logseq would add a persons-involved:: property to the block and when I type Nicole Logseq would suggest some property values that contain Nicole and, if I choose one by pressing Enter, it would automatically add to the persons-involved:: property. I am thinking that the Value would be a namespace in the form of Nicole/Blanc/customer/personal-training/. An even better option would be when properties can have sub-properties (I believe this was already suggested in the forums) so I can have:

persons-involved::
    ::Nicole/Blanc::
        role:: customer
        via:: personal-training

So maybe now you see why I misuse or understand incorrectly namespaces. Like I said, for me namespaces are personal, Nicole will most likely always remain, for me, a customer of my side-gig “personal-training”. But I mostly see namespaces as means to make clear for me what is the relationship in that particular situation and also for a way to be able to pick up that block in searches, queries, etc. With complex queries it might be possible to traverse the database and search for all property-names that have a role of customer then search for all blocks where those names are mentioned and also where a personalized-plan of type exercise is mentioned. But if most of these data would already be in the bloc I wouldn’t need such complex queries I believe. There is a trade-off between complexity and extracted value so that’s why it’s good to have a sense of the common-sense amount of data you add to each block and how.

I it were you, how would you tackle this simple block:
I met today with Nicole to hand her the exercise plan I built for her.
so that you can query for customers to whom you delivered an exercise plan?

PS: I made up all this story so I might not have chosen the best example but I believe it is enough so I can understand namespaces through it with your help…

16

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).

17

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?

18

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.

19

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:

20

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”)

2 Likes
21

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.

2 Likes
22

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.

23

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/
    etc.

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:

sidebarquery
sidebarquery710×631 56.2 KB

1 Like
24

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:

2 Likes
25

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.

26

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.

27

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
28

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
29

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).

30

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
31

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

1 Like
32

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?

33

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
34

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