I deployed the Johnny.Decimal SBS for my startup, and so far it’s been working a treat. However, we just don’t use the JDex and it seems to me an unnecessary step, and I’d like some input on whether we’re just doing it wrong, or whether we just don’t need it in our use case.
When we go to create a new file, such as training on our password manager, we just navigate through the file tree to end up at 11.51 Mandatory Training. If we need to find it again, Obsidian search brings up a list of all files mentioning it, and backlinking allows us to link to it from other pages(e.g. a document on how to set up a new network, we can link "Don’t forget to store logins in #1Password). We simply don’t add it to the JDex and when we need to find it nobody uses the JDex to find it…either the file tree is easily navigable and we can just…browse the tree to it, or we search for it.
This is all it is. It’s just notes that aren’t files in a filesystem. That’s the trap people fall into: thinking that filesystem === system. Or in your case, filesystem === business.
Of course your business is more than just its files. It’s all of these notes and whatever else you might record in Obsidian. And things in other places (cloud services, say?) whose locations you might record in Obsidian. Otherwise, how would you remember that they existed?
That’s all your JDex is. It sounds like you’re using it as it was intended? What am I missing? What do you think you’re not doing that I might say you should be doing?
None of the backlinking is done in the JDex, they’re done in other files. The JDex file has pretty much remained untouched since deployment, but I see in many places “add it to your JDex” in documentation.
The original JDex files that came with the system.
Your own notes.
And you’re doing the work in 2?
Eh I think you’re still in the spirit of the JDex. Question though: when you create a new ID, do you add a JDex entry? Or do you just create a filesystem folder?
If the latter, this is where I encourage caution. You don’t think you will, but believe me, it’ll happen: you create an ID somewhere, and you create another ID somewhere unrelated, and you end up using the same ID. That’s the core function of the JDex: it’s the central record of IDs.
We never deployed the JDex files, we have 00.00 JDex which has remained untouched. When I create a new file, for instance 11.41 Hiring, creating a job posting, we just share in slack “ayo you can find the text of the job posting in 11.41” and the person knows the folder they can find it. No JDex and although I guess it’s possible we make a duplicate ID, we pretty much look in the folder and create the next available number, so we are training our staff to avoid duplicate IDs.
The JDex is the collection of files in which you take notes about the important things and locations in your business. It’s not just the 00.00 file. As distributed in the SBS, this is single folder with a bunch of text files. It sounds like you’ve created the (empty) folder structure with the JD numbers, and put the text files in there as you create them start using those folders. If Obsidian search and backlinks are working fine to surface note files inside that folder tree, then I think that is exactly the functionality of the JDex concept. And if you have the category folders pre-created, there’s some safeguard against creating duplicate IDs.
I myself also use plain text index.md files alongside other type of files (docs, images, spreadsheets …) in ID folders. So I don’t have the JDex files in a separate tree from the ‘data’. Of course, some things are stored elsewhere, but I have notes recording that.
I think the bottom line is that if you only keep your “stuff” (i.e. the ID’s with their content) in one “place” then you might not need a JDEX. But if you have multiple places you certainly do. In my case, my “stuff” is in DropBox, OneDrive, DevonThink, and a few cases in Obsidian. So my JDEX is a reminder/pointer to where stuff is (and I keep it separately in DevonThink).
I feel the same. The power of separate JDex notes really shines when your data is spread across multiple locations, including physical folders! That’s why having dedicated index files (or a single unified index page) is so important to me for keeping everything connected.
At work, I have information in email, notes, files, Microsoft ToDo and an assortment of enterprise tools like Jira, Confluence etc. Not having a central index is a big problem, for all the reasons talked about in this thread.
When I deploy JD (I’m in the discovery stage at the moment) it’s going to be a real habit shift to use the JDex, but I’m going to try hard to build that habit.
Great observation. It is a difficult habit to form. We’re so used to treating our filesystem as the source of truth. Still, today, it’s my natural instinct.
I guess @sasquatchnetworks can confirm this is what they’re doing, but it seems like there’s a safe middle ground where you keep the JDex in a folder structure rather than as text files in one folder. You fill out the whole folder hierarchy of AC.ID folders, and their presence serves to inform you which IDs already exist. Then you add plain text notes in those folders, as well as whatever other files fit naturally in there. And note the existence of other locations in note note text files.
So lots of people have noted the importance of having a separate index when the things being indexed can be in multiple locations. I suggest that if your setup handles it, you can move jdex and ‘file system’ into one circle, while still being able to reference other locations (email, cloud storage, etc).
Are there counter-arguments, other than that keeping the index really separate helps to see it as a distinct location, for the sake of building the habit of going to the index first?
I guess it comes down to whether your tools support this. There have been discussions before about needing to configure Obsidian to not try to index non-text files, for example, otherwise performance degrades. Using a generic search tool, you could tell it to search only **/*index.md files first. I have scripts to create a new folder with the right ID, and then to create an index.md file in that folder with the ID and title in the file’s frontmatter. In this way I’m using my filesystem as the JDex/single source of truth. It’s where I always look first, and seven times out of ten the actual files are there, so I can skip the Index step safely (since it is the index), and three times out of ten I need to consult the index file to know which file to look for, either here or elsewhere.
Just one final broader note. I think this is an example of how files-and-directories do not map to how we perceive and work with the world. The fact that we’re always going in circles trying to decide how to implement a ‘Johnny Decimal ID’ shows that a concept like that doesn’t fit in this model. We need a kind of ‘container’ format which can have an ‘index note’ attached to it, as well as ‘attachments’ or ‘children’, whose physical storage location may be abstracted away. From the Web world we get the convention of folders with index.md files, but it’s not the optimal model.
This, to me, is the only reason for a JDEX. File folders on my computer/cloud don’t contain all of the stuff I save – my JDEX tells me where everything is.
I’d say this, plus JDex = content for me. E.g. at life admin’s 15.11 Places I've been, or want to go, that note is where I list those places. (Latest entry.)
I don’t also have a document/database/whatever. The note already existed. So ‘setup time’ was zero seconds: just start typing.
Ah, you’re right. A JDEX doesn’t just ‘point’ to locations, it can also contain information in the JDEX notes. It actually took me quite awhile to grasp that so no surprise I overlooked it. The point is covered in the section on ‘Why I love my JDEX/I never re-use IDs’ and also noted by @hans post that ‘the convention of folders with an index’ is not quite the right model.
Thanks for the friendly amendment. By always going to my JDEX I often find what I need right there!
One other quick thought of the benefit of a separate JDEX. When I start a new project, I think through carefully whether it fits in an existing area, category or ID before I create a new one, and going through the existing categorization helps reduce folder proliferation.
Indeed, when I set up JD fully a year and a half ago and went through all my files to categorize them, I found related stuff hither and yon in multiple folders that have now been consolidated.