FR: Bottom-up Dendrons (Alternative hierarchy suggestion)

[dleeftink]

Currently, hierarchies can be deduced from note names as follows:

root.branch
root.branch.leafA
root.branch.leafB

This requires notes to be arranged into hierachies up front/top-down. I would like to propose Dendron hierarchies to be created bottom-up as well, by including dot.notated.sequences in the note body.

Use case

For instance, given notes named as follows (e.g. a flat list):

news.md

weather.md
sports.md
football.md
tennis.md

newsItemA.md
newsItemB.md
newsItemC.md
newsItemD.md

I would like hierarchies to be inferred from dot notation, wherever these might be encountered. For instance, newsItemA.md might be categorised by writing [[news]].[[weather]] in the note body (or YAML/header based on user preference).

Similarly, newsItemB.md might be categorised by writing [[news]].[[sports]].[[football]], and newsItemC.md by writing [[news]].[[sports]].[[tennis]].

In fact, newsItemD.md might be categorised both as [[news]].[[sports]] and [[news]].[[weather]], akin to nested tags. However, in contrast to nested tags the proposed scheme allows notes to exist anywhere in the vault.

Ideally, hierarchies are parsed from either [[linked]].[[notes]] and regular.text and possibly even autosuggested (!) based on previous linkages. I am not sure weather Breadcrumbs can handle this, but multiple parents and recursion/self-loops might be handled by defining certain notes to be roots, branches or leaf nodes or via graph traversal.

Corollary

The use case I am envisioning is classifying unstructured notes based on existing/non-existing notes in the vault. This enables you to 'slot in' concepts in the hierarchy you have not necessarily written about, but are common to existing hierarchies (e.g. including hockey as a branch in the above news example without creating a note called hockey.md).

Importantly, hierarchies can be infinitely rearranged: football and tennis might sometimes be children of sports, while at other times children of exercise (in other contexts exercise might itself be part of sports).

Additionally, this is a very compact way of building hierarchies in leaf notes themselves, only requiring a .dot notated string of existing/non-existing notes.

While from graph theoretic perspective, these ambiguities complicate inferring hierarchies (e.g. determining what the main 'parent' is of a single note), from a NLP perspective some parents might be more frequently associated with children than others. Over time, hierarchies might stabilise by virtue of some child/parent notes being associated more frequently, allowing true bottom-up generation of note hierarchies. Combined with autosuggestions, new notes can be easily added to the hierarchy in a single line, while concurrently expanding the Obisidian graph view.

Let me know if this lies within the realm of implementation:)

Possible schemes

Inline code:

• dot.notated.sequence

A nested link:

• [[dot.notated.sequence]], overriding Obsidian default behaviour

Dot separated links:

• [[dot]].[[notated]].[[sequence]], allowing links to be updated on Obsidian file name changes.

Regular text:

• dot.notated.sequence without any markup, keeping a parallel index of non-exisiting branches/leafs.

[SkepticMystic]

Hey @dleeftink, I appreciate the effort you've put into this FR! One big issue that comes up, is that syntaxes 1, 3, and 4 that you propose at the bottom all require parsing the full content of every note in the vault. That's alot of computation to do, and no other feature requires that, so I can't even hook it into that. The cost of so much parsing makes me also certain that I won't do it that way. The other syntax you propose comes with other issues where Obsidian will start looking for a note [[dot.notated.sequence]], when that's not what it means. I don't want to get into the game of monkey-patching Obsidian's link parsing, so that one is also unlikely...

I am certainly open to something like this, but it can't be super costly, and I don't want to override Obsidian code, either. I hope you understand. I'll keep this issue open in case you or someone else has other suggestions

[dleeftink]

Hi @SkepticMystic, thanks for reviewing this proposal. Essentially I am thinking of accessing/referencing notes akin to standard JSON. I was afraid this would be quite heavy processing-wise, and I've thought up two possible solutions:

1. Bottom-up dendrons as YAML/Dataview fields

   • Instead of parsing the full note body, allow hierarchical note categorisation via a predefined YAML or Dataview field (e.g. BC-branch: news.sports). The entries might be a list of dot.separated.sequences to add the current note to one or multiple hierarchies.

2. Ghost folder of Dendron notes

   • Whenever a link is encountered that follows the [[dot.separated.branch]] notation, a branch note with the same name is added to a user defined hierarchy folder (e.g. dot.separated.branch.md to a folder called myHierarchy).
   • We can introduce a constraint to naming and parsing such links, e.g. only allowing sanitised words following underscore/Camelcase conventions between 3 and 16 (or more) characters:
     • For instance, when adding a valid Dendron link in a note named fieldHockeyGameResults.md, a 'branch note' called news.sports.fieldHockey.md or news.sports.field_hockey.md might automatically be generated and added to the Breadcrumbs hierarchy.
     • This approach keeps in line with current Obsidian linking behaviour, including autosuggestions when typing links.
     • Additionally, this allows the user to merge branch notes and update branch links via the standard Obsidian merge function, resulting in a flat folder of notes following the Dendron naming format (each branch note essentially a mini-MOC that can be edited).

A combination of the above might also work! Let me know what you think.