Headers ■

J.D Concepts 11 Core concepts
1

I was going to type this as a reply to this post from @ontologist but that thread is about extend-the-end, and this question is about something entirely different. Here’s the key bit, from the end:

On to the question.

This is a problem I have – unresolved – with use of the headers that we introduced with Life Admin.

I have no problem with them in that context. That is an essentially fixed system. It is designed to be static. We left 2 IDs free under each header just in case, but the intent is, you use it like it came. Similarly, area 10-19 Business administration in the Small Business System.

But then we have SBS category 21 Products & services 💈, which comes empty. Because I can’t define your products & services.

So I’m currently in the process of defining my own structure there. And when I use headers, which feels nice because I’m encoding a further level of semantics, I start to feel a little nervous. Because this isn’t a static system. I’m adding new IDs every day.

Here’s what I’ve got so far.

z-CleanShot 2025-06-09 10-44-07@2x
z-CleanShot 2025-06-09 10-44-07@2x716×1436 92 KB

The problem

Of course is one of unpredictability. Here I sit, days in to this new structure, and how can I know what’ll be busy and what won’t?

Explaining this to others

As per the other thread, this feels like I’m straying in to unexplainable territory. Which is a red-flag. What rules, heuristics, guidance would I give you, other than to just spend a day trying to plan it before you start?

And would that be okay? Especially in this context where you’ve got SBS for free (mentally, not monetarily lol :money_mouth_face:) and so the only thinking you need to do is in this category context?

So…

I think I’ve answered my own question. I think I’m going to roll back and abandon headers in this category. So IDs will follow the ‘old-school’ JD way: they’ll appear in the order that they were created, and will be all over the place. Number theory might follow Small Business System might follow Academic research. Whatever. Get over it.

Perhaps, then, I should at least put all of my old stuff at the top. The workbook, workshop, life admin, and small business systems, in that order, which is the order they were created. Then all the other stuff I just need to free-form, creating IDs as I go.

Agh. No. I don’t know. I read this over and over and my mind changes each time. Headers are so neat…

So I won’t change anything yet. I’ll post this and wait. The discussion in the other thread was tremendously useful.

2 Likes
2

Counter-point: headers force me to think about the structure of my products. Isn’t that a good thing?

1 Like
3

Yes - but it might but a while before you can use it! It took me months and many iterations to get a structure that lasted more than a few sessions of trying to file stuff. Now its just right, but that’s a lot of time being in less productive mode.

4

That is what I always liked about TeX/LaTeX et.al. not hiding away the complexity of the task but putting it right in front of me. However I think that headers can very well be changed or added afterwards. For me it took quite some time and I also moved several things around in the index before everything felt somewhat right. While doing this is quite a lot of work it pays off in the end.
My approach for “empty” categories is meanwhile that I usually “leave some room” i.e. don’t pack my IDs tightly so it is easier to insert headers or other stuff in between later.
Also I try to think before or experience during working with it if I need something to be “cluttered” across several IDs (or extended). Meaning if I need to access a specific subset of a “thing” inside an ID regularly I move it into it’s own ID or more likely into an extension of the origin ID. If I need to access the whole set of “things” inside an ID anyway when I’m working on it then I leave it underneath the ID. This breaks the “no sub-folders” rule but so far this works good for me because either I have only a few things or I simply create a dedicated structure (usually for client jobs which is somewhat fixed and nearly always the same) underneath it and “zoom in” if working on it.

I hope this doesn’t sound too confusing. :sweat_smile:

1 Like
5

Thinking a bit outside the box here.

What is the essential purpose of headers — or even EtE, for that matter? It’s simply to group things.

But IDs beneath the category level are intentionally free-floating (in some cases, an additional layer of semantic encoding is acceptable). That’s their strength! We’re not supposed to spend time crafting brittle, hierarchical systems that may or may not stand the test of time.

So what’s my almost blasphemous solution to that?

Use tags.

Tags are born for this task. Anything you want to see as a group gets the same tag. And the best part: you can add multiple tags to a single item if necessary!

To keep track of the tags you’ve used in a category, just document them in your index file — e.g., 11.00 Index for category 11. This supports search and helps avoid the temptation to overload your identifiers with meaning.

In short:
Use IDs to locate, tags to relate.

1 Like
6

Another Shoot from the Hip: Linking

If we need to group existing IDs, we can create a new group folder with its own ID.

Inside it, we place links to the related folders, which remain at the ID level.

This forms an identifiable group without moving folders.

Also, include the grouped IDs as defining references in the group’s index note.

Example

22.10_Tools/
22.11_Editors/
22.12_Security/
22.13_Networking/
22.14_Storage/
22.15_Backups/
22.16_2FA-Devices/
22.17_Passwords/
22.18_Certificates/
22.19_Keys/
22.25_SSH-Keys/
22.26_SSO-Systems/
22.27_Credentials-Group/
├── 22.16_2FA-Devices → ../22.16_2FA-Devices/
├── 22.17_Passwords → ../22.17_Passwords/
├── 22.25_SSH-Keys → ../22.25_SSH-Keys/
22.28_API-Tokens/
22.29_Identity-Providers/

What I Am Suggesting

There are two main organization tools besides folders: tags and links. We should leverage these tools when we need to build semantic structure, and let the JD system handle the job of locating things.

7

I think tags and/or links are valuable for some things, usually additive, but what we’re talking about here is the primary organisation of your structure. And so I think that needs to be encoded in the structure itself, and not rely on secondary mechanisms (which aren’t supported in your filesystem in a reliably cross-platform way).

8

There is a fundamental tension between encoding semantics into identifiers (mirrored in the folder hierarchy) and maintaining flexibility. This tension can’t be resolved by folders alone—but perhaps it can be eased by other means.

At least tags are somewhat universal—since you can always include them in the folder title.
That’s not too far from EtE, e.g.12.13 Stuff [Group1].

I can also imagine a MOC (Map of Content) index file or ID as an identifiable reference list of related IDs.

These may not be neat solutions, but they promote a separation of concerns: identification versus classification. In the end, it’s all about trade-offs.

9

Grouping Through Nested IDs [Breaking Change]

A folder-only approach that trades sorting for grouping could be to allow nesting ID folders inside one another. This creates identifiable groups of related IDs, but the identifiers themselves do not capture the hierarchy. Include references in the JD notes to document the parent-child relationship.

Of course, this breaks sorting, but you can still reliably reach your destination using the search bar. You can still view all ID folders by searching for ‘AD.’.

10

Interesting. I’m not gonna do it, but it’s interesting! I appreciate all of these ideas.

1 Like
11

All this talk of header IDs and ETE reminds me of my experiment last year encoding the structure of things in IDs. The idea was to use deepening numbers similarly to how many product databases do it – 1000, 1100, 1103 being related products. Here’s my conclusion to that thread:

Mostly induced by @johnnydecimal coaching me back from adding this complexity :wink:
I wanted to try this out partly because of seeing header IDs. So I find it interesting that they are still causing restlessness.
@ontologist has brought some excellent professional wisdom to bear here. With my experiment in mind, I would emphasize: JD is about making things findeable, and it works because the categories you create are fake. As soon as you start encoding real-world structure, your filing system’s days are numbered. I suspect that will be confirmed experimentally as a Law of Information Management at some point if it hasn’t been already.

I agree about the tags or groups. As long as it’s a closed set, itself crafted in an intentional way.

3 Likes
12

JD × Zettelkasten?

Ever wondered what a fusion of Johnny.Decimal and Zettelkasten might look like? Here’s one possible result — and personally, I like it. That said, I’m not sure how well it holds up under real-world conditions and how JD and Zettelkasten could be completely harmonized.

For context, here’s a solid introduction to the Zettelkasten method, which blends surprisingly well with JD in this use case:
:backhand_index_pointing_right: https://zettelkasten.de/introduction/

2025-06-11_01-46-47@2x
2025-06-11_01-46-47@2x718×1110 147 KB

1 Like
13

This is interesting. With the usual caveat that it’s the user’s responsibility to not let any system that might get out of control, actually get out of control.

But I like how this gracefully allows for expansion above 100 IDs/10-per-header without being totally loose.

At the end of the day, how ‘deep’ you go is a matter of personal comfort. @whinyaan on Discord – not sure how much they hang out here – has this wild scheme that ends up like 22.01.0008.20.010 … but it works great for them. They’re running a business with many customers and IIRC each one of those nested things basically mirrors the top-level structure but ‘inside’ a customer account.

For now I haven’t changed anything and will just be keeping an eye on it.

1 Like
14

My company’s JDification of our old system is nearing its end, and the result is a mutant. Is that of interest here? I can post the structure once it’s done.

1 Like
15

Please! Maybe in its own thread?

16

Interesting …

For what it’s worth, I see @johnnydecimal has removed the headers from our 21 Products & services folder for now.

I am happy.

It made me nervous that we’d just moved into our shiny new folder structure and there were barriers. In this scenario, I would prefer freedom to create, over further organisation. :rainbow::victory_hand:

I understand (and like) headers in the context of a fully pre-made system like Life admin because we had the advantage of organising a set number of things. And trying to make things as clear as possible for new users.

But for the record, I’m totally cool in 21 Products & services with IDs being next to each other, but not the same as each other. I just pin/unpin stuff on my side bar depending on what I’m working on. Just like for anything in 50-59 Portfolio of creative outputs.

For other businesses whose 21 is more rigid, they might prefer headers. Or maybe in 2 years we might see that 21 has settled and decide to add headers then?

1 Like
17

@ontologist, cool. That’s the Zettelkasten infill identifier system allowing new items to be inserted without disturbing the existing order.

If we’re introducing mutants, I’ll mention the Noguchi Filing System here. Basically: sort things by most recently used. Whever you take something out, always put it back at the front of the stack. The NFS takes this to the extreme in the sense of it being the only organisation principle in the system. There are a handful of articles around arguing that if you’re going to choose a Most Recently Used stack as your only organising principle, it will almost always serve you well because the last time we touched something, or the last place we saw it, is pretty salient in human memory.

I think NFS could work very well as a complement to a fixed ordering system, be that the infill system or classic JD AC.ID. I would envision being in last modified order during daily use – when looking for things – and switching to name order when inserting something new: where should this new thing go in the coordinate system I’ve created?

Obviously you could use last modified time sorting inside ID folders, as well as for ID folders themselves. In the latter case I think dispensing with category folders would be helpful.

Another way NFS pairs quite naturally with JD is in that NFS doesn’t proscribe an ‘archive’ filing system alongside the working stack. The idea is that on a regular basis you look at the things that have migrated naturally to the back of the stack, and either delete them or move them to a static archive. For which JD would be very suitable. However, if that’s all JD would be doing we wouldn’t be able to admire our beautiful numbering systems very often. Hence I’m currently trying the other approach of actually sorting my ID folders by mtime and will report back when I have more data.

@Don_F I would also like to hear more about your results when you’re ready!

2 Likes
18

Okay, next week probably.

19

Ah god this is such a delightfully simple idea I feel physically sick that I didn’t think of it.

Now … thinks … does macOS bubble up changes to folder contents to the mtime of the folder itself? Do the *nixes? Will do some testing.

(Although with a JDex-first approach, which I’m trying hard to do by ‘checking in/out’ of a note as I touch the item, all you need is the mtime of a single note. Your file system is not your system…)

1 Like
20

Might depend on the app, but in principle yes.