My way of adopting JD in Obsidian

J.D Concepts 14 Build your system
1

I use Obsidian with folder-notes plugin and Obsidian Base queries (new standard plugin replicating good old Dataview)

My current areas (top level folders in vault), just to give a context for better understanding examples below.
For now I have these areas:

  • 1 Life - Life Admin adapted to my needs.
  • 3 Tech - my job and hobby, programming, computer science, …
  • 5 Mus - lifelong hobby playing guitar, gear, music theory, studio, …
  • 7 Atlas - general knowledge, my local wikipedia, things I’m curious about but not proficient at, things that do not fit into other area and don’t require a separate area yet.

Suggested folder structure by JD spec looks like this

10-19 Life admin/
├── 11 Personal/
│   ├── 11.01 Inbox
│   ├── 11.40 ■ My Family
│   └── 11.42 My Kids
├── 12 Home/
│   └── 12.25 Mortgage

Things I didn’t like in JD standard folder structure

  • 10-19 Life admin folder naming looks like 10.19 while it’s not - extra cognitive load when I see it in obsidian’s folders breadcrumb path at the top.
  • The Area index is nested too deep 10-19 Life admin/10 Life admin management/10.00 Life admin index
  • It is hard to write a common query for a template, I can’t just write file.inFolder(this.file.folder), because Area Management is not a parent folder of area content.
  • I was torn between what to put where, there is confusion between 10 and 10.00

So I made a couple of changes in suggested folder structure for me.

Everything-is-ID Folder Structure

I made every folder to follow AC.ID format, merged Area and AreaCategory into single folder note.

My Variant 1: area/category/id

10.00 life/                       (Area scope and index) 
├── 10.01 inbox/                  (area-level standard zeros)
├── 11.00 personal/               (category scope and index)
│   ├── 11.01 inbox/              (category-level standard zeros)
│   ├── 11.40 ■ Family/           (heading AC.ID)
│   └── 11.42 Brother/            (regular AC.ID)
├── 15.00 travel, events/
    ├── 15.30 ■ Events/
    └── 15.35 Music concerts/

30.00 tech/
├── 31.00 programming/
│   ├── 31.20 ■ Languages/
│   └── 31.22 Python/

50.00 mus/
├── 52.00 gear/
│   ├── 52.20 ■ Amps/
│   └── 52.21 Tube amps/

Each folder has its own folder-note in it, e.g. 10.00 life/10.00 life.md

Notes AC.00 and A0.00 can be templated with index queries like this

filters:
  and:
    - file.inFolder(this.file.folder)
    - file.hasTag("JD/ID")

Tags.

  • 10.00 is tagged with three tags #JD/A, #JD/AC and JD/ID,
  • 15.00 is has two tags #JD/AC and #JD/ID,
  • regular deepest AC.ID notes are tagged only #JD/ID.

optional Variant 2: nest heading AC.ID as well

10.00 life/
├── 11.00 personal/
│   └── 11.40 family/              (heading becomes subfolder)
│       └── 11.42 brother

Pros: more consistent AC.ID is 4 digits, so 4 levels of nesting, easier to index heading IDs with queries, e.g 11.40 Family
Cons: too rigid and too deep structure, so I will stick with variant 1 for now.

Usage of Wasted IDs A0.10-A0.99.

There is a gap of unused IDs between area-level standard zeros and start of first AC in the Area, in Life Admin area, these are 10.10 - 10.99
So I have an Idea to use them for:

Cross-Area Referencing

Extension: Use unused IDs (10.10-10.99) for cross-area relationships
Spec by example: given Areas 1 Life admin , and 5 Musician, I can have:

  • 50.10 ◾ Mus area items related to Life admin area
  • 50.11 Daily guitar practice routines
    this can work both ways
  • 10.51 Daily Guitar Practice log

If this is overthinking for you, you can always use wasted IDs for regular Area-wide things or don’t use them at all.

I’ve just started and I’m still in the process of implementing and adapting this approach - I might change some things along the way. What do you guys think about all this?

1 Like
2

Welcome to the community! I like your approach, it’s thoughtful and clearly tailored to how you want to work in Obsidian. That said, it’s helpful to keep in mind what JD is fundamentally about: a system for identifying and locating folders where work gets done. The classification into areas and categories is intentionally coarse to keep the structure shallow and flexible. For more on this, see this post on headers by @hans.

Regarding headers: these are meant for special cases where you know in advance that you’ll have no more than 10 headers and 10 items per header. Beyond that, headers carry the risk of requiring re-indexing, so I would advise against using them extensively.

As for using JDex-style IDs for area and category folders: strictly speaking, it’s not necessary for location and retrieval. But your decision seems well thought-out, especially to address aesthetic and technical needs in Obsidian. So in that context, your adaptation makes sense.

If you’re starting from scratch, I also recommend checking out this thread for a smart alternative approach to organizing standard zeros and area management: Alternative layout for the standard zeros

On cross-area references: JD encourages placing each item in a single, clearly defined location, based on where it’s most actively used. If something belongs to multiple contexts, consider using links or tags.

One final point: I’ve found that I tend to overcomplicate the JD structure. But I’ve come to appreciate that Johnny Noble’s approach is the result of years of practical use. He deliberately avoids adding more complexity than necessary, prioritizing ease, speed, and low-stress organization when storing and finding your stuff.

3 Likes
3

I also always struggle with the ‘cognitive load’ of navigating the nested file structure. I would prefer to have everything be completely flat, since the numbers take care of sorting. I retain parent folders for two reasons:

  1. Syncthing needs folders to know what to sync
  2. GUI file managers become unworkable with unnested folders.

Regarding point 2, some TUI file managers have useful features like ‘flat view’, but nothing really solves this completely. I think the files-in-directories model is starting to burst at the seams. We need a view on files an directories that works like folding in a text editor.

That’s why I’m all for keeping the structure as shallow as possible. As I said further down the thread @ontologist referenced, we humans have a better memory for where things are in long lists than we think.

So… Keep experimenting with what works for you!

I break the rules in the same way. Every folder at whatever level is allowed a file index.md. I find this works fine for me.

2 Likes