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 atAC.ID, and express additional parent-child relationships through links in the JDex instead. In practice, a parent JDex note lists itschildren, and optionally child notes point back to theirparent. 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.
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+Linuxand11.43+MacOSare children of11.43_OS;11.46_Windowsis also a child of11.43_OS;11.45+Vimis a child of11.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.
