I’ve been experimenting with using indices for atomic items that live inside my JD folders. For a long time, I’ve been generating these indices as simple timestamps (e.g., 20250927221057) and adding them to the titles of items.
Originally, I used doing this in Bitwarden, but over time it expanded into other areas of my system.
This got me thinking: what if I created dedicated index files, each titled with the index (e.g., 20250927221057.md), and inside those files I kept links to all the JD-index locations where that reference appears?
How it would work
- Each index file functions like the back-of-the-book index: it shows everywhere a given index is used.
- Typically, I designate one item as the referenced item.
- Other items become referencing items, pointing back to the reference.
- The index file then documents both:
- Referenced item → the “source” location.
- Referencing items → one or more “target” locations
The part I’m still unsure about is where these index files should live:
- Should I keep them in the same folder as my JD index files?
- Or should they live in a separate folder, acting as a distinct sublayer of indices?
I’m also wondering: is this extra layer of indices actually useful, or does it risk overcomplicating the system?
Can we see a real-world use of this?
Where in your system would one of these atomic things appear twice? That feels like a requirement for this to be useful?
I use references, e.g., 20250411175319, inside Bitwarden since it doesn’t support linking entries directly. For example, I connected all entries related to 03.35 NAS-24 SFTP-for-WP-Backup (the referenced entry), which is the account dedicated to a specific backup task on the Synology device. These entries are spread across different JD folders.
In my Obsidian vault 03.26_Obsidian_JD, I’ve added instructions for my future self on how to enable port forwarding to back up my website to my Synology NAS.
In ChatGPT, I have a conversation on the same topic. Unfortunately, it’s not yet possible to search conversations by title.
I’m wondering why not just use the JD ID though, or an extend-the-end pattern if that’s not granular enough?
03.35 is already a way to ‘reference’ that backup job. I’m not sure what the timestamp is adding? What am I missing?
If you need a more specific reference, 03.35+REF1 or similar?
In my own notes for example, I just wiki-link everything together. So 14.11+curium which is a server links to 14.21+hal6000 which is a 16TB storage array that’s plugged in to it, and 14.32+ Backblaze which is the backup service I use(d, need to update this), and so on.
These links are definitely useful. I want to get in the habit of, when touching that backup service config in any way, making sure I reference all linked elements in the note so I can’t accidentally forget that I configured it on 14.11+argon or some other server.
You’re right — 03.35 NAS-24 SFTP-for-WP-Backup wasn’t the best example. Normally, entries are kept inside JD-indexed folders, but in this case I merged the JDex and the entry into one for convenience. I’m trying to make it clearer what I’m aiming for:
Location 1:
- Area 1
- Category 3
- JD 13.14
- Item
- …
- Item [reference X]
- …
- Item
- Area 2
- Category 7
- JD 27.23
- Item
- …
- Item [reference X]
- …
- Item
Location 2:
- Area 3
- Category 2
- JD 32.42
- Item
- …
- Item [reference X]
- …
- Item
Location 3:
- Area 3
- Category 3
- JD 33.27
- Item
- …
- Item [reference X]
- …
- Item
This [reference X] connects items across multiple JD folders and systems. All of these items are related in a meaningful way but are stored in different places. A centralized index, as proposed, could help maintain an overview of these related items.
Hmm I guess I’d still just like to see that reference X as a JD ID? Do you have room for a new category to hold those?
Because then references – I totally see what you’re going for – are a first-class citizen. You can look them up and search for them like you can anything else in your system.
1 Like
Thanks for nudging me back on track. The cleanest solution is probably to spin up a dedicated “special case” category, something like 04.00+XXXX (or even just 04.XXXX for simplicity?). That way references become first-class citizens in the system, with enough room in the numbering pattern to handle them properly.
Cool, let us know how it goes. It might not work, but I’d like to know that before trying something else.
