Revisiting EtE

[ontologist]

Continuing the discussion from Extend-the-end + vs. 01, 02:

The Problem

Recently, I ran into the same issue that @johnnydecimal described above. I’ve been indexing devices and their associated accounts using sub-IDs, like so:

• 13.13 NAS
  • 13.13+01 Main Account
  • 13.13+02 My Sister’s Account
  • …
  • 13.13+11 SFTP User

But when I want to add a sub-note to one of those, e.g. 13.13+01 Main Account, I hit the same wall:

13.13+01+ More Stuff

The solution we previously came up with was to reassign the child note its own main ID, like this:

13.17 Main Account

to get

13.17+ More Stuff

But that approach bothers me now, for three reasons:

1. I want all related accounts to stay together, so I don’t accidentally overlook one.
2. Accounts are children of devices. Main Account is a child of NAS, and I want that relationship to be reflected in the structure somehow.
3. Any child could eventually become a parent of another note, forcing me to reindex.

A Different Approach: MOCs (Maps of Content)

To avoid these issues entirely, I’m considering dropping sub-IDs in favour of something more flexible, but just as powerful.

The idea:

I create a parent note.

And all the child notes are simply linked or referenced inside this parent note. That gives me a clear parent–child relationship without the fragility of sub-IDs. The structure remains flat while depth is now handled through flexible linking.

So, if one day I want to add a child note to 13.23_SFTP-User—say, “Stuff about SFTP”—I just create a new note like:

13.27_Stuff-About-SFTP

…and link it inside 13.23_SFTP-User.

No need to re-index. No confusion about where things are. Infinite depth, if I want it, achieved via linking, while following standard AC.ID_Title JDex format.

Sub-Notes

In this scenario, + only serves to divide a longer note into smaller notes. This is for structural purposes and does not imply any commitment to a parent-child-relationship

Beyond 100 Items

To quote the example use case on the JD website:
If you create more than 100 blog posts, then instead of using something like 22.00+0000, you use 22.0000.

Not all of those (potentially 10,000) items might be blog posts, some could be related child notes with their own JDex. If you need a clean overview of blog posts only, simply link each blog post ID into 22.0000.

Grow As You Go

If the MOC note 22.0000 should ever become too long, you could either split it into sub-notes using 22.0000+, or assign those parts their own JDex and link them into a new unifying MOC note. There’s really no limitation when it comes to MOCs.

[hans]

@ontologist

No need to re-index. No confusion about where things are. Infinite depth, if I want it, achieved via linking, while following standard AC.ID_Title JDex format.

So to find something, you follow a trail of links?

@ontologist

In this scenario, + only serves to divide a longer note into smaller notes. This is for structural purposes and does not imply any commitment to a parent-child-relationship

So the + kind of means ‘include this’ or ‘additionally’?

[ontologist]

@hans

So to find something, you follow a trail of links?

It depends on your entry point. You can go up or down from the chain of links as necessary. Most important: You eliminate the need for sub-IDs. My main point is: You find the parent note and see all its children. Of course if you might follow the trail up or down you could do it.

@hans

So the + kind of means ‘include this’ or ‘additionally’?

I think Johnny Noble intended + mainly as a convenience, just a way to break a note into smaller, more manageable sections for organizational clarity. You could easily merge them back into one without affecting the logic or structure of your JDex. So in that sense, yes!

[ontologist]

@ontologist

Beyond 100 Items

On second thought, the simpler solution (for a clean separation of concerns) would be to use one category for blog post notes and another for related child notes. Then, link the child notes to their corresponding parent blog posts.

[ontologist]

By the way, MOCs could also serve as a viable alternative to headers when the number of child or parent items could exceed ten. For a reliable overview, you can also link all header-like notes into a single unifying MOC note, such as the category’s index note.

[johnnydecimal (Johnny Noble)]

If it’s data related to the structure of the system, I’ve always preferred to keep it ‘above the line’ in a metadata-like block.

In Bear that means Key: Value pair-like notation, in a blockquote, above a <hr>. The blockquote is purely cosmetic, and the <hr> tells me what’s metadata and what’s content.

I do the same in Obsidian. I’d like to settle on a standard baseline of metadata keys (that you can expand), but I’m not there yet. Recently I was playing with emoji to indicate links and whatnot. Ah here’s a relevant example just using arrows.

Of course Obsidian formalises this with YAML metadata. I don’t use that because I find just typing it out faster, and I don’t query this data so having it structured isn’t a benefit. But I should probably migrate.

Ah that’s right, and if you create parent-child links in Obsidian, your graph mirrors the structure of the system. I was playing with that but, as most have realised, the graph is pretty, but useless.

[ontologist]

The question of how to store this type of metadata is currently holding me back. But, at the moment I gravitate to store them in the YAML frontmatter (for consistency and plugin compatibility).

What you see in the image above on the right side is the Excalibrain plugin. It seems to be infinitely more valuable than the link graph. Maybe you find this demo video inspirational!

[johnnydecimal (Johnny Noble)]

@ontologist

Maybe you find this demo video inspirational!

Must … resist … distraction …

[ontologist]

[ontologist]

An ontologist’s dream comes true, I can fully visualize relationships!

• Green links represent regular child notes.
• Red links indicate where JDexes were used. In this example, all index notes correspond to an index folder instance located in 13.25_Bitwarden (my personal Bitwarden account).

This looks very promising.

[ontologist]

To all Obsidian users: if you like storing metadata in YAML, such as a list of links to child or parent notes, you can make Obsidian display each bullet point on its own line in Live Preview, regardless of window width, by adding a small CSS snippet.

Here’s what it looks like:

Heads-up: Search in Live Preview does not highlight matches inside YAML. Switch to Source Mode if you want highlights.

Place the CSS snippet in your .obsidian/snippets folder to enable it:

/*********************************************************
 * Properties → Multi-select pills
 * One pill per row, left-aligned, content-width pills
 *********************************************************/

/* Stack vertically, but don't use gap (we'll space pills via margins) */
.metadata-property .multi-select-container {
  display: flex;
  flex-direction: column;
  align-items: flex-start;   /* left align pills */
  gap: 0;
}

/* Each pill hugs its content width */
.metadata-property .multi-select-pill {
  display: inline-flex;
  align-items: center;
  max-width: 100%;
  white-space: nowrap;
  width: auto !important;
  margin-bottom: 6px;        /* spacing between rows */
}

/* Remove extra margin after the last pill (before the input row) */
.metadata-property .multi-select-container > .multi-select-pill:nth-last-child(2) {
  margin-bottom: 0;
}

/* collapse by default */
.metadata-property .multi-select-input {
  height: 0;
  min-height: 0;
  padding: 0;
  margin: 0;
  border: 0;
  opacity: 0;
  pointer-events: none;
}

/* expand ONLY when the input itself has focus */
.metadata-property .multi-select-input:focus {
  height: var(--input-height, 28px);
  padding: var(--size-2-2, 4px) var(--size-2-3, 6px);
  border: initial;
  opacity: 1;
  pointer-events: auto;
}