Hi guys, been reading a lot on namespaces and am still in the same cloud of not understanding how and why to use them. I started using namespaces when Logseq got it’s Hierarchy so I can actually see the main topics and to have aminimal structuring and categorization within my graph. But it has become a drag and I am thinking of scraping it completely and relying on actual tags (which can be a good thing as they can show some connections that hierarchical namespaces will prevent) or turning it on its head and, instead of having Logseq/Template to have Template/Logseq, Still, with this latest approach, the TAG way has more freedom to it. If I want to search for Templates in general I would write #Template while if I want to narrow it down I would filter it from the #template page (or search for bot tags in a search). What I lose with this approach is the Hierarchy, which is nice to see but not sure if it adds more than some clean overview.
What is your take on this? and Is the graph the only other way to see all tags/pages if they are flat (no namespace)?
It is simple in essence, namespaces are surnames: When two persons have the same name, we differentiate them by their surname. The name is template, the surname is Logseq.
Now THAT is a very simple, and clear way to explain the concept. Like @FlorianF I was struggling to fully grok it.
Your simple explanation also makes clear what you meant when you wrote
To put it in human terms, if John is the only John around, his surname is irrelevant. If there are 2 Johns in the group, it is important to call them John Smith and John Harrison.
Namespaces are a great way to create some top-down structure in your graph, but at the same time, you shouldn’t use it for everything.
I only use namespace for a very few “domains” of my life, and mostly for topics within those domains. Then, the actual content (blocks and pages) are tagged with that namespace.
So, for example, you could have a namespace hierarchy like this:
OS/
Windows/
MacOS/
Linux/
Then, when taking a note about Windows, you would tag to OS/Windows.
Btw, one of the best use cases for namespaces I have is to create an index of values I use for the type:: property.
For every new type I create, I add it as a child of the graph/types, and also give it a shorter name as an alias (which is what I actually use as a value in thetype::property).
This way, all of my defined types are grouped together, could easily be found with a simple namespace query, and, because of the alias trick, instead of using type:: [[graph/types/quote]], I use type:: [[gt.quote]].
And of course, the graph namespace is where I store some other stuff related to my graph, such as templates, custom props, dashboards, etc.
Yes, but you got the formatting a bit wrong. type must start with : and gt.quote should be wrapped around double square brackets, so, in the end, the result will look like this:
Under the hood, Logseq’s implementation of namespace does more than just making names unambiguous. I think The Most Legit Use of Namespaces boils it down quite well.
These are opinions. If you like a particular approach, feel free to use it. The OP has been aware of the most legit abuse of namespaces (as per his post there from one month ago), but still has not found peace. So it is important to further clarify.
All fine, no offense. I am unsure myself, when and if to use Logseq namespaces at all. So far I think, they don’t scale well with growth of knowledge graph and substituting them with above alternatives in most cases leads to better graph structure. Excited to see, if I change my mind again after couple weeks of testing.
I have read that one and many more on Namespaces and I am struggling because I don’t see them now like I did in my post in the “The Most Legit use of Namespaces”, with a root and then branches all the way out. Right now I consider namespaces to be there for dis-ambiguity. With Logseq is easy to rename [[John]] into [[John, Smith]] down the road, if another John needs to be mentioned at some point and I need some differentiation. My question was about using tags instead of namescapes as a more natural way to get the same results (I think). So, for example I would write in the Joutrnal: - Finally the [[Audi]] [[car]] we bought one month ago has arrived in the local dealership.
Of course you can have a namespace [[car/Audi]] but why and how use that instead of the more natural language above? If I only wrote: Finally the car has arrived then it would make sense to tag it #[[car/Audi]] or, the way I would do it: Finally the [car]([[car/Audi]]) has arrived. But I wouldn’t because writing in a natural language is a better option in my opinion. Actually I wouldn’t even tag such a sentence. If we query for the text “car” and “Audi” we should get the same results as they are found in this, this and this blocks.
When I started using Namespaces in Logseq I followed some online suggestion to have a whole hierarchy starting with "my/" and going some pretty deep hierarchies which are biting me right now for increasing the friction of adding data. I now tend to agree on having only “some” namespaces which are just former Tags with another layer of disambiguation but without any tree with a common root. I mostly see it useful for hierarchies that are more than 2 or 3 layers deep. Like I mentioned in my post in “The most Legit use of Namespaces”, business projects seem to need deep namespaces (ex: ‘side-gig/personal-training/customers/Nicole/personalized-plan/exercise’) that can’t be constructed in a natural language because they are too complex. I would write: I met today with Nicole to hand her the exercise plan I built for her. Now, based on the data in the sentence, can’t I infer that Nicole is a customer for whom I have built an exercise-plan? Do I really need the other tags in the namespace? I must surely know that I am conducting a side-gig and offer personalized diet and exercise plans to paying customers… For sure, when Nicole has contacted me, I must have tagged her as a personal-training/Nicole. So there is the namespace.
To sum it up, my understanding so far is that there can be the need for namespaces when you want to be able to 1) differentiate and 2) query. So disambiguation and visibility. For now I only have one Nicole as a customer in my personal-training side-gig so if there would be another Nicole at some point, I might want to add another namespace there. But for better visibility, the more complex the namespace the more ways I have to see it through the different lenses. If I want to list my customers for all my side-gigs I have to have that tag attached to their name, other wise this particular case can’t be achieved. So where is the sweet-spot? Should I built, from the start, at least the most common-sense namespace and then add to it along the way when I get into ambiguity issues?
I think it’s a good idea to always use names that you know are less likely to conflict with something later in the future.
Btw, in your case, I would actually have an individual page for each client, with the names being person: full name and with a page property like is-client:: true, or a specific tag, or something like that.
Also, for linking, I would rely on markdown links, not just simple wiki links, just for aesthetics. It would look like this: I met today with [Nicole]([[Person: Nicole something]]) to hand her the exercise plan I built for her
Lastly, If the client had some unique nickname, I would add that as a page alias
That is generally true and it should be the starting point. There should be a good reason to introduce something unnatural (like namespaces and tags). Your examples help a lot the discussion.
This is madness for multiple reasons. Among others, imagine if tomorrow Nicole turns out to be a more important person (e.g. the mayor) or changes to a more important one (employer, wife, whatever). Disaster, all these links become misleading.
Should never have to jam extra info into a name. Nicole is a person. If you are forced to categorize her, it should be [[person/Nicole]]. Being a customer is coincidental.
If you know her surname, please use this. If not, make up a surname or nickname yourself. Actually the first surnames were exactly that, e.g. [[John the miller]] became [[John Miller]] (later meaning “a descendant of the miller”). Everything else about Nicole should be placed into Nicole’s page.
Her name is just an address to refer to her whole page. In this case the actual address, not an alias. Think of it as a meaningless number (not a quantity, but a mnemonic), just easier to remember. Should not have to parse a name for information, should just use it to find its page and process the info there.
Likewise, should not have to describe the car, only to identify it:
[[our car]], if this is the only car that we will ever have
[[our Audi]], if this is the only Audi that we will ever have
[[our first Audi]], if we have more than one
something else that is convenient
This note contains pieces of info that:
should be moved to the referenced page:
something mentioning [[car]]
something mentioning [[Audi]]
something mentioning the date of buying
should be either:
the value of an appropriate property, if it is important
a mention inside a simple note, if it is a detail
don’t need their own pages, unless we need to put something inside
The thing to keep in the journal is the event, in this case the arrival. Everything else should be finally moved to its proper page, keeping just the links. Even the local dealership is a candidate to move out. If you have event-specific info, should be put into sub-blocks. Ideally:
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:
I can write naturally my input, without tailoring it to the Logseq Page Name (I met today with [Nicole]([[Nicole/Blanc]] ));
I prefer a Markdown Link then a double bracket enclosed text and
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:
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…
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.
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 …
This is my current understanding on namespaces, feel free to help me (and others) improve it
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”)
…