As I mentioned in the discord, I do not see myself using this proposed notation. I lived for a while with my system (which you probably remember), so here is how it differs and where I see advantages.
Any sub-note gets +
Doesnāt matter whether it is arbitrary or extend-the-end. Reason: I only want to know that it is not an id definition note. This symbol is normally used only in the index.
Exception: sub-notes without id in the note
In some cases I donāt want id in the note name at all. So I just put them under id directory in the Obsidian. Examples: people notes, recipes, knowledge notes. Usually these are where I have lots of notes per id.
23.14 toto.md
23.15 Yoto content.md
23.15 Yoto content\
- 0011 Mes comptines.md
- 0012 Pass-Partout.md
23.16 blah blah.md
This is very specific to how I use Obsidian, with semi-flat structure! In normal situation these should look like 23.15+ 0011 Mes compines.md .
Labels get @
Labels are kinda like tags in the filenames. They are used for things like country codes, people short or long name codes. Examples:
-
11.11+ @AA name change.mdnote and11.11 ...\@AA\Name change\directory- Label is used as a directory name because there are a bunch of files like
11.11 .../@AA/@BB @CAN passport.pdf
- Label is used as a directory name because there are a bunch of files like
-
11.12+ @SurnameN @CAN visa.mdnote and11.12 .../@SurnameN @CAN visa/directory -
11.12 .../@BB @KAZ passport.pdffile -
15.41+ 2024-07-31 @AA to @MNE via @AUT.mdand15.41 .../2024-07-31 @AA to @MNE via @AUT/directory -
13.54 .../2025 @CAN taxes/1 Inputs/@BB/2025 @BB some form.pdffile
Advantages are pretty obvious, but letās be explicit:
- You can use several labels in the same file or directory name
- Label can exist any any level. It might be right under the ID or in the templated directories deeper down like in taxes
- There are separate notes for people in my Obsidian, like
11.41 My partner. It has aliases pointing to the labels@AAand embedded base that looks for any notes with@AAin a name. @as a symbol is easy to remember because it is often used as a label in other apps.- Symbol is attached to the label which IMHO makes it easier to search for.
- Your proposal to use
+ AAmight cause more false positives. It shouldnāt, but it might. + AAis less obvious when used anywhere in the filename (not just in the beginning)
- Your proposal to use
So, what about your examples like + Work-log and + Meeting minutes? Thatās an interesting idea. Normally, all my @labels donāt have any spaces and follow tag-safe structure. One similar thing I have is @OPS label for operational manuals. I agree that using free form text reads natural. Thus, maybe 21.35+ @Work log.md ?
Logs
Actually, I have some AC.ID+ blah blah log.md notes. I might switch this to AC.ID+ blah blah @log.md structure. I am mostly interested that these files are dated logs but they might be different logs: work logs, health logs, tantrum logs, etc.
Extend-the-end
Iāve come to believe that EtE is several techniques in one. All of them have the same goal: adding āsub-idā capability. What this sub-id pattern defines how it is stored in my system:
Dated EtE
E.g., taxes or travel information. Something that has a date first. In such cases I donāt see a need for any additional symbol to prepend. So they are stored as is. For taxes I donāt have sub-notes in Obsidian, so itās only visible in the filesystem (see example 6 above). For travel I have sub-notes and sometimes directory in the filesystem (see example 5)
Labelled EtE
Typically used as a shadow system for other family members (see example 1).
There are cases like example 2 when I donāt have dedicated directory for @SurnameN under id: this is usually for more āproject-likeā events for people I donāt generally track in my system (e.g., grandparents).
Advantage of using label in this case is that since their files can happen in places like taxes, using search for @AA is way easier in the eventual case when I will hand down some of these files to them.
āI donāt careā EtE
Might be controversial one xD But for things like 13.51 Credit cards even if I have sub-directories with bank names, I donāt really care about labeling them, because I wonāt search for this thing across all system. So, in the index it might be (or not) represented as a normal sub-note 13.51+ blah blah.md and there might be (or not) directory 13.51 .../blah blah/
Numbered EtE aka id-based work packages
In rare cases when you want to have work package inside the whole id but there are no natural sub-id, I just assign some numbers. Here how it looks like in the filesystem:
23.15 Yoto content\
- 0011 Mes comptines\
- 0012 Pass-Partout\
When I need to reference this somewhere outside Obsidian I can use 23.15+ 0011 Mes comptines.
~ for work package id linking?
I donāt use this pattern yet, but I agree that this symbol feels the most natural.
Though, if I would like to go very fancy, I might use 
emoji. Because why not, itās not like Iād use it very often.
Do you list you EtE titles in your JDEX? I see another use case, which I may start adopting shortly.
Lets say I am on the Committee on Widgets, which I have given an ID of 41.11
This committee has several projects. Does it make sense to do
41.11- Making Widgets for Japan
41.11- Making Widgets out of Balsa Wood
etc.
Intriguing. My rule has been to create an Obsidian folder whenever I have multiple notes for an Id (and donāt want them under structured headers in a single note).But using AC.ID~ would be faster.
I really like the distinction between relational notes and one-off notes. Are the + EtE's intended to be limited to one per file. For instance if I have a summer camp contract that covers 2 children, could I have: 12.34 Summer Camp Contract+ Thing1+ Thing2 (the spacing on this is confusing).
Iāve been doing something like this with - preceding any meta info about a file. One suggestion I would make is to have the identifying character attached to the keyword, i.e. 12.34 Summer Camp Contract +Thing1 +Thing2
A further example of my - system that I happened to be using this morning is for my property tax files:
14.2026 -123 Main -Real Estate Tax -Borough -Invoice -$123.00
14.2026 -123 Main -Real Estate Tax -School -Invoice -$1230.00
14.2026 -456 Center -Real Estate Tax -County -Receipt -$234.00
There are a lot of weird nuances in that example that may not pertain to other systems, but this -tag system has been really helpful for me to for finding things visually or through searches. With that said, the + and ~ are much more unique characters that add some interesting functionality.
Not sure I would need the + and ~ destiction - I would probably make a folder under the ID and then utilize the Work Package notation when needed (I am doing a ton of āprojectsā (think a bunch of tasks that combined make a delivery on a deadline.
TL;DR
I would use+for one purpose only: to mark a dependent child or sub-note of an existing ID. Repeated concepts such as people, locations, or note types are a separate classification concern and should use tags or keywords instead. Most child notes should inherit their parent ID; only permanently subordinate aspects should receive a stable sub-address.
Keep structure and classification separate
I support formalising the notation, but I would not distinguish ~ from + based on whether a sub-note is arbitrary or repeated elsewhere.
Both represent the same structural relationship: the note depends on an existing ID and does not define an ID of its own. I would therefore use + for all child notes:
11.11 Birth certificate
11.11+ Notes from applying for a UK copy
21.35 JDHQ
21.35+ Meeting minutes
A note may begin as a one-off and later recur elsewhere. That should not require renaming it from ~ to +, because its relationship to its parent has not changed.
In examples such as 11.11+ Belinda, the + currently carries two meanings:
- this is a child of
11.11; - this belongs to the reusable category āBelindaā.
I would separate them:
11.11+ Birth certificate @Belinda
11.25+ Vaccinations @Belinda
21.35+ Meeting minutes #meeting-minutes
The exact tag syntax can remain a personal choice.
Persistent addresses
Most child notes are simply extracted headings or dependent aspects of their parent. They inherit the parentās ID and do not need a unique sub-address.
A genuinely permanent subordinate aspect may occasionally benefit from a stable sub-address, for example:
11.12+SUB Linux
However, I would only assign one when I am highly confident that the aspect will never become an independent entry. Most child notes could eventually grow into independent things, so assigning them a unique sub-address too early would undermine address stability.
Until that happens, they should remain unaddressed children:
11.12+ Linux
Once a child becomes independent, it should be promoted to its own JDex:
11.12+ Linux ā 11.17 Linux
So my preferred model is:
- an ID identifies an independent entry;
+identifies a dependent child;- tags/keywords provide optional cross-ID classification;
W0011@12.34remains a separate formal syntax for linking work packages to IDs.
These feel like they should just be their own IDs, vs. trying to jam them all into one.
We need to be careful with EtE: itās a tool to be used sparingly.
The worst offender in my own business is the SBS 14.32 External software and services. I have a bunch of EtEs there:
+ Airtable
+ Baserow
+ Discord
ā¦
+ Vimeo
+ Zoom
I donāt love that I have this many, but each contains such a tiny amount of data, itās okay.
If any of those needed to contain large amounts of data, Iād need to create a category for it and give them each their own ID.
This was the broad consensus in the Discord discussion on this topic: why bother with my complicated ~ when you can just create a folder and put your notes in it?
It depends how you name your notes. Personally I like every note starting with the ID. But Raven on Discord doesnāt, e.g. they have:
āāā 43.11 š« Coffee Inventory, Reviews, & Recipes
ā āāā 20th Anniversary Blend by Nossa Familia.md
ā āāā Alvaro Rodriguez LPET by Hydrangea.md
ā āāā A.M.O.C. Colombia Rosado.md
ā āāā Andres Cardona Purple Honey by KOS.md
ā āāā Andres Martinez Gesha from Hydrangea.md
ā which I can see being more practical if you have hundreds of notes. I typically donāt have that many.
Use sparingly, for sure. But I guess this would work:
12.34 Camp + Child 1 + Child 2
----------^^^^^^^^^
ā because any text parser will easily handle a rule like āfrom the plus up to but not including the start of any other plusā, and pick out the 2 children.
So are you using the - to indicate to yourself that this is like a āreserved keywordā? As a consistency tool? Interesting ā¦ yeah I think thatās basically the same idea as my +, taken to the next level.
One of the reasons we like them so much is that they solve many of these problems by giving you this āextended spaceā thatās way far away from the ID.
This is certainly the most popular of the alternative suggestions. And the main reason that Iām hesitant to use the @ in my WP notation.
Also, as Iāve discovered (and had validated by a heavy @ user on Discord), it feels very heavy between the characters, e.g. W0123@12.34 ā especially when seen in a list. I much prefer the ~, visually.
I think it depends on how strongly you distinguish metadata from content. I place anything that is essentially a collection of content notes in its own ID folder.
A + child note, by contrast, represents an aspect of the entity identified by the parent note and therefore belongs to the metadata layer. Any substantive content related to that aspect would be stored in a corresponding subfolder:
11.12 OS/
āāā 11.12+ Linux/
To be honest, Iām not really tech savvy enough to do text parsing, but this system allows me to put keywords on the end for quick visual identification of what the contents are. It also helps when Iām searching because I may remember the keywords better than the name. Itās not a defined and limited set of keywords, just trail markers for me while Iām searching*.
For instance one of my freight vendors has a folder of: Armstrong Transport -Freight Broker -Freshwater Freight -Collections ACC [L21.073]
This breaks down to:
- Business Name of Vendor:
Armstrong Transport - What they provide:
-Freight Broker - Related company that bills through Armstrong:
-Freshwater Freight - Transaction Description
-Collections ACC - ID at the end so the folders sort alphabetically:
[L21.073]
Thatās an admittedly convoluted example, but I wanted to share a worst case. I kept seeing Collections on my bank statements and scrambling around trying to figure out what I forgot to pay before I realize that itās just the ānameā of the vendor. This helps me search if I canāt remember the Business Name
Similarly in my project files, I generally add -3DPrint or -Machining or -Design or -Research to the end of my IDs to aid in searching for broader categories. For instance these projects are spread out over my projects folder but a quick search narrows it down:
Iām using one commander to for my file browser and it doesnāt like spaces in itās simple search bar which is what led me to the attached dash.
*Iām not really sure what the difference between filtering and searching in this conversation is, but I use the terms interchangeably.
I tried this method early on, but it ended up in too many āthingsā under the same ID and typing the ID plus keyword seemed cumbersome and missed the point of a numerical system. For me creating a 3 digit ID made it easy to add just the AC.ID to all of the contents without needing to keep repeating the keyword.
I may be misunderstanding your comment here so please forgive me it thatās the case.
Thanks for raising this. My reason for keeping unaddressed children under the same ID is precisely the limit of 100 IDs per category. I see that limit as useful: it encourages me to reserve addresses for entities important enough to deserve one.
The unaddressed children are dependent aspects of those entities. They also serve as a staging ground: if one later becomes independent, it can receive its own ID.
Even with an AC.XXX format, I would want to preserve this distinction. I do not want to assign unique IDs to every small dependent item, thereby cluttering my address space, when it is clearly just part of a larger entity.
That makes sense. Iāve been prioritizing shallowness over shortness but I can appreciate doing it the other way around.
The one I struggle with is the SBSās 14.32 External software & services, which I use ā¦ āheavilyā isnāt the right word. I have a lot of things there, but theyāre lightly used.
I have 39 things in there, like:
14.32+ 1Password
14.32+ Airtable
14.32+ Amazon SES
14.32+ Arq
14.32+ Backblaze
14.32+ Buttondown
ā¦
14.32+ Zoom
Thereās a couple of things at play here.
Lightly used
Like I say, I use this list lightly. Mostly if I want to wiki-link to one of these services in Obsidian; I like how the note then becomes a pointer to all the places through my system where I use, say, Arq (backup software).
For example hereās + Caddy, a web proxy utility.
Thatās all the services that use Caddy. Neat!
Better alphabetically
This is a textbook example of a list that works better alphabetically. Sorting by ID-as-allocated-at-first-use makes no sense.
ā¦but I kinda wish they each had an ID
Or do I? As I type it out I think I assume that I wish each had an ID. What I was going to say was that I had considered breaking out 14.32 to its own category. We already have 39 things, that feels category-like.
What Iād do would be to use 14.32 as a pointer, even renaming it like 14.32 External software & services ā 62, telling me to go over to category 62.
But now I think on it, Iām not sure that really gets me anything. I just said I donāt need these things sorted by ID. My little + list works; thereās nothing wrong with it.
Maybe Iām over-thinking it? Maybe if I did spend a bunch of time in these places then it would earn a promotion to category. But I donāt.
I think your gut feeling aligns with a core principle: limiting our choices to increase clarity. The address space is deliberately constrained, so the real question is which things genuinely need to be uniquely addressable.
If something already has a clear place within an existing ID and you do not need to address it independently, there is little reason to promote it to its own ID or category. In that case, the answer can confidently be āno.ā