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/
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 withinProject 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 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.
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 . 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)
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.
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.
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.
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.
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,
or
PointName, PointDescription, GeoXPoint, GeoYPoint, GeoZPoint, DateCreation, TimeCreation, EditorCreation, DateChange, TimeChange, EditorChange.
Both ChangeDate and DateChange carry the same information. The rest is how we perceive the meaning of this information, which is about useful conventions. So, by convention:
the slash character / in a/b means “b (when considered) within a”
Logseq/template means “template within Logseq”
a capitalized word signify a uniquely named entity:
Logseq is unique
template is not
uniquely named entities don’t need namespaces
In Logseq’s namespaces, the slash convention is enforced. But it is the user to decide which name is considered within what other name, based on the meaning of “within” in each occasion:
Logseq/template, i.e. the concept of template within Logseq
that makes sense for templates supported in Logseq
template/logseq, i.e. logseq within the concept of template
that could make sense if there was a template named “logseq”
change/date, i.e. the concept of date within the concept of change
that makes sense when referring to the date of each change, i.e. the change-date
date/change, i.e. the concept of change within the concept of date
that makes sense when narrowing changes to those which target date, i.e. to date-changes
This is about namespaces. Other areas (files, fields etc.) may follow different conventions. For example, in javascript it could make sense to write file.changeDate = Date.Change() and define the class in file DateChange.js Some conventions are more meaningful than others, but being consistent is more important.
There is neither stupid/question, nor Question.Stupid
mentaloid thanks for the quick reply.
The concept of conversations is still very foreign to me. So I did not know the different meaning of upper and lower case yet. I will have to deal intensively with the different conventions.
I have learned a lot via this discussion and wanted to document this learning in LogSeq, particularly on the topic of LogSeq namespaces.
So on today’s journal I have an entry to this discussion and linking to “LogSeq/namespaces” page - as the topic page, where I will later enter some some proper notes about namespaces in LogSeq, suggested uses etc.
So I have created a namespace for namespaces! It seemed that LogSeq as an application will have a set of features / concepts that can be enumerated within it, namespaces being one such. Based on the above discussions, I think this would be an acceptable use of namespaces, not likely to cause me issues?
More broadly, the main signal that pushes me towards thinking of using a namespaces, is because the path information in the namespace itself seems part of the identity of the thing - i.e like an address., I.e. wouldn’t make sense to address that content any other way, because there is an issue of a potential address conflict in the future.
My frustration with namespaces is that, they enter my mind as I encounter and am entering new content, and take my mind out if its flow to start going through mental hoops to design a hierarchy. This is often in the hopes that there is some perceived and tangible benefit that by linking my content appropriately to its suitable “final destination” right now (even if that destination page in that hierarchy is initially empty), it will be easier to later come back to in future and see its related content via backlinks. This is all just additional friction at the point of entry
For this reason, I am beginning to favour the idea of just getting content down first and avoiding introduction of any “ad hoc” hierarchies until that can be well thought through - where there is any uncertainty. I am thinking uncertainty and confidence in hierarchies is going to be prevalent especially in new users, like me!
. 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.