JDex & Maps of Content (MOCs): A Flexible Alternative to Header IDs

The Johnny.Decimal system Concepts
1

TL;DR
Header IDs solve a real problem: they group similar things together inside of categories. But they also encode another layer of hierarchy into the ID space, which can design you into a corner if the system keeps evolving. My proposal is to keep the Johnny.Decimal ID shallow at AC.ID, and express additional parent-child relationships through links in the JDex instead. In practice, a parent JDex note lists its children, and optionally child notes point back to their parent. This turns “headers” into flexible MOCs: they still provide overview and structure, but without forcing related IDs into fixed blocks of ten.

Background

This post is a continuation of my earlier thread: Revisiting EtE. The pattern I proposed there was:

Keep the JDex structure flat, and express deeper relationships through links.

I also mentioned that MOCs could serve as an alternative to Header IDs when the number of child or parent items might exceed ten. This post is meant to develop that idea more explicitly. Instead of focusing on EtE and sub-notes, I want to apply the same pattern specifically to Header IDs.

For me, the core distinction is:

Header IDs group by number range. MOCs group by relationships (links).

The Problem

At the ID level, Johnny.Decimal gives us up to 100 IDs per category. But we often like to group similar items together.

One way to solve this is to use Header IDs. A Header ID groups the category into blocks of ten, for example:

11.40 Header
11.41 Item
11.42 Item
11.43 Item
...

This is useful mostly static and carefully designed system. But it also adds another layer of hierarchy to the ID itself. The problem is that this hierarchy is fixed by the number range. If the system changes later, the header structure may no longer fit.

This is the same basic tension I kept running into:

How much structure should be encoded into the ID, and how much structure should live outside the ID?

IDs are excellent as stable addresses. But if we put too much semantic or hierarchical meaning into them, they become harder to change.

The Proposed Solution

My proposal is to keep AC.ID as the stable address and avoid encoding further hierarchy into the ID itself. Instead, the JDex note should define relationships between IDs: links express parent-child relationships, turning the JDex note into a MOC.

This keeps the ID system simple, while still allowing it to grow and reorganize over time.

Example

The figure below shows the idea. Parent-child relationships are established by links. The arrows point from parent to child.

2026-05-0213-28-55
2026-05-0213-28-55781×1058 35.5 KB

In this example, 11.43_OS acts as a parent note for several related IDs:

---
created: 2024-11-29T18:53:52
modified: 2026-04-26T22:19:19
tags:
  - JDex/10-19_Life/11_Workspace
locations:
  - "[[03.21_Raindrop]]"
  - "[[03.53_ChatGPT]]"
old-titles:
  - 11.24_MacOS
children:
  - "[[11.43+Linux]]"
  - "[[11.43+MacOS]]"
  - "[[11.46_Windows]]"
---

This means that 11.43_OS is a normal JDex note that also functions as a MOC.

Corresponding Folder Tree

The folder tree could look like this:

10-19_Life
├── 11_Workspace
│   ├── 11.42_Tools
│   ├── 11.43_OS
│   │   ├── 11.43+Linux
│   │   └── 11.43+MacOS
│   ├── 11.44_PKM
│   ├── 11.45_Terminal
│   │   └── 11.45+Vim
│   ├── 11.46_Windows
│   ├── 11.47_Gaming

But the conceptual structure is primarily defined by the JDex.

For example:

  • 11.43+Linux and 11.43+MacOS are children of 11.43_OS;
  • 11.46_Windows is also a child of 11.43_OS;
  • 11.45+Vim is a child of 11.45_Terminal;

This separates the storage location from the conceptual relationship.

Suggested Rules

To keep the system predictable, I would use a few simple rules.

1. A parent-child relationship must be documented

It should be recorded in the JDex, for example with a children property.

2. A child should have at most one parent

This keeps the structure tree-like. Ordinary cross-links can still exist, but I would not treat them as structural parent-child relationships.

3. A child can be dependent or independent

3.1 Dependent childdren

A dependent child shares the same base ID as its parent, for example:

11.43_OS
11.43+Linux
11.43+MacOS

This means the child is part of the parent ID. If the parent disappears, the child probably disappears too.

A dependent child must be linked to its parent MOC and must not have any children of its own.

3.2 Independent children

An independent child has its own separate ID, for example:

11.43_OS
11.46_Windows

This means the child is important enough to have its own ID, but can still be conceptually linked from a parent MOC.

4. Parents should usually stay inside one category

I would avoid parent-child relationships that cross category boundaries. Cross-category relationships are better handled as ordinary links or references, not as structural parent-child relationships.

5. Old IDs should be documented

I keep an old-titles field to track previous names or IDs. This helps when the system changes over time.

6. Removed IDs should leave a marker

I also like to keep an AC.ID_EMPTY marker when an ID is (re)moved, so available IDs are easy to spot later.

Conclusion

I am not arguing that Header IDs are wrong. They are useful in stable, carefully designed systems.

But in an expanding system, I think they introduce too much fixed hierarchy. MOCs offer a softer alternative: they give us overview, grouping, and navigation, while keeping the actual Johnny.Decimal IDs simpler and more flexible.

So my current rule of thumb would be:

Use IDs for stable addresses.
Use MOCs for flexible structure.