What I don’t get from this blog entry is where you are supposed to store the JDex in case of multiple systems, like those described in My data storage & backup strategy.
D85 Johnny.Decimal (the business)
D01 johnnydecimal.com (the website)
P76 Johnny's personal life
L77 Learn with Lucy (the Excel course)
Z99 Archive some old long-term archives, including some data that isn’t mine
In this case, each of those system should have a JDex inside their corrispective 00-00, generating five different vaults? If you want a global JDex I think you can only store it externally, maybe inside a J00 JDex system? I’m curious about the approach you people have used.
D01 has always been neglected, as it’s the structure you see at https://johnnydecimal.com. So it’s kind of self-documenting, and honestly changes very infrequently; as a result, I’ve never had a proper JDex for it. But it needs one.
P76 is my personal system and it lives in Bear. More on this below.
L77 was created retrospectively as we recorded the course before I quit my job to be Johnny.Decimal. It’s also 100% static. So there isn’t a proper JDex for that.
Z99 the same, basically.
But let’s say that I did want a central, all-in-one JDex for this stuff. Honestly I’m getting close to merging D25 & P76 as not being able to link them is annoying often enough. I love Bear but it’s becoming inconvenient. So yes, you’d need some sort of master JDex.
(Assuming, of course, that you want these things in the same vault. That comes with its own set of issues. Primary of which is using the quick-opener will now show you conflicts for every ID. Other than qualifying every single ID with the full SYS.AC.ID I’m not sure what you could do about that.)
A00 is how I think about this. A00.00.00 is the first thing in any system: so it’s the only place that a shared JDex could live. I like J00 as well though. Same idea, different letter.
But like I say, I haven’t actually done this, so that’s about as far as my thinking has got.
Thanks for your reply. You are absolutely right about the conflicts; I hadn’t considered that. Also, a SYS.AC.ID structure seems too heavy to handle in a note-taking app.
My context
Just to be clear, I think it’s helpful to share my context so that anyone passing by can decide if my ideas apply to their own situation:
I need a clear separation between my personal and work environments. I want to index both, but their organizational logic is fundamentally different. Working in hospital management, my work setup must be highly flexible. It needs to host a massive volume of items that range from strictly private to shared with specific teams or individuals. Furthermore, changing hospitals is a concrete possibility in my field, meaning I regularly need to spin up entirely new systems.
Despite this, I want a complete JDex within a single vault. Multiple vaults increase sync costs and break cross-linking. I need unique, easy-to-type IDs across the board.
The SAC.ID System After some thought, I’ve landed on a highly opinionated SAC.ID approach. I might be reinventing the wheel, but this feels like the most conservative way to maintain unique IDs across multiple systems. Here, the S stands for a single-digit System number. I am keeping two different types of systems:
1. Indexed Systems (0-9)
System 0 (Personal): The 0 prefix is omitted in the file system and JDex, making it behave like a classic Johnny.Decimal setup (e.g., 0PR Personal Environment).
Systems 1-9 (Work): My current hospital is System 1 (e.g., 1CR My work environment). Future appointments will just follow the enumeration (System 2, System 3, etc.). Using a number prefix works perfectly since the numpad rules in my office environment—it adds almost no typing friction. It also allows me to optionally drop the S prefix in shared folders for the sake of simplicity for my colleagues.
Note: This is similar to the official Expand an area concept, but applied to the system level to allow for entirely separate systems rather than expanding an area. Extending the end remains my favorite method to expand my folder trees at work.
2. Non-Indexed Systems (Letters) These are for systems with intrinsic folder structures or dump systems like archives. They start with a letter:
X86 App Libraries: Applications don’t like their libraries being touched. I place these in a separate “app system” within a folder named after the app (e.g., Obsidian, Zotero, Calibre).
Z99 Archive: Self-explanatory.
I hope this overthinking proves useful to someone! As always, any comments or suggestions are welcome. This is a work in progress, and this community is incredibly helpful.
It was a delight to read. Thanks for taking the time to think about it so thoroughly – I always say, the system is a starter, a guide. Adapt it to your needs. I’m sure this will help someone in the future.
I use two systems in the same Obsidian vault. Every ID has the full SYS.AC.ID code in its name. At first, I found that a bit cluttered, but I got used to it pretty quickly.
My workplace is commonly abbreviated by a three letter acronym (“KIM”, pronounced like the name), so this became the SYS code. Therefore, none of my colleagues raise an eyebrow if I share a folder with them that starts with KIM.17.13. Well, I guess some find it odd that the folder starts with an alphanumeric code in the first place, but at least KIM.17.13 doesn’t look weirder to them than 17.13 would, possibly even less.
For me and my use case, it was a good decision not to follow Johnny’s naming convention for my system: If I had called my system K49 or something similar, that would be more confusing to read in a list of files that all carry this prefix. And the communication with coworkers might be a bit more awkward.
