I’m not sure that I understand your question, could you get more specific? For their conceptual difference, read this answer.
:view.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.
Many thanks for your simple analogy.
Are namespaces worth it?
Yes, totally
What is your take on this?
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:
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 the type:: 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.
So, your query for type quote would look like this:
{{query (property type gt.quote}}?
I aoplogize if my question is simplistic, I am still learning about properties and queries.
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:
{{query (property :type [[gt.quote]])}}
You might as well define your custom namespace:
Template (Logseq)Logseq templateUnder 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 oneThis note contains pieces of info that:
[[car]]
[[Audi]]
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 met today with [Nicole]([[Nicole/Blanc]] ));[[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…
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 
…
This is my current understanding on namespaces, feel free to help me (and others) improve it 
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:
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:
