Nested tags in the U/I

[rcarlan]

Consider the following tags hierarchy:

• Tags
  • A1
    • B1
      • C
  • A2
    • B2
      • C

If I drag an item/article (let’s say I1) onto A1/B1/C, I expect it to inherit the following tags: A1, B1, C. Similarly, if I drag a group/folder (G1) onto A1/B1/C.

Conversely, if I drag an item/article (I2) onto A2/B2/C, I expect it to inherit the following tags: A2, B2, C. Similarly, if I drag a group/folder (G2) onto A2/B2/C.

The end result should look like this (where I placed the tags in between square brackets):

• Tags
  • A1
    • B1
      • C
        • G1 [A1, B1, C]
        • I1 [A1, B1, C]
  • A2
    • B2
      • C
        • G2 [A2 ,B2, C]
        • I2 [A2 ,B2, C]

I can confirm that this is indeed what happens. Great!

However, once the tags have been assigned (based on the corresponding hierarchy), the information about how they were assigned is lost – at least as far as the user interface is concerned. There doesn’t appear to be a way of identifying which C was originally assigned. And, also, whether the other tags (A1, B1 or A2, B2) were manually assigned or inherited.

DT does appear to differentiate between the two Cs. That’s apparent from how the items/groups are shown under the Tags hierarchy. But also if, for example, I drag I1 onto the C under A2/B2; it ends up with the following tags: A1, A2, B1, B2, C, C.

There are two things that can happen here:

1. Accidentally tagging an item or group with the C tag from the wrong hierarchy.
2. Intentionally (or accidentally) tagging an item or group with both Cs.

In both of these cases, there’s no easy way of identifying which of the two Cs the item/group has been tagged with (or, indeed, which C is which, if the item/group has been tagged with both).

It’s worth noting that DT lists tags in alphabetical order. So, while my example above looks somewhat intuitive (e.g. G1 [A1, B1, C]), in real life this is unlikely to be the case (as the nested tags hierarchy is unlikely to be alphabetical). In fact, I1 [A1, A2, B1, B2, C, C] already illustrates this; but it can get much worse (where the two Cs would still be next to each other, but the other tags would be completely jumbled up, depending on their actual names).

The above example may seem farfetched to some. So, here’s a more relatable example:

• Tags
  • Apps
    • Obsidian
      • Extensions
    • VSCode
      • Extensions

Now, consider articles for an imaginary VS Code extension: “Ultimate VS Code Extension”. One may want to tag these with the Extensions tag from underneath Apps/VSCode.

Similarly, articles for an imaginary Obsidian plugin: “Ultimate Obsidian Plugin” would be tagged with the Extensions tag from underneath Apps/Obsidian.

It will end up looking like this:

• Tags
  • Apps
    • Obsidian
      • Extensions
        • Ultimate Obsidian Plugin [Apps, Extensions, Obsidian]
    • VSCode
      • Extensions
        • Ultimate VS Code Extension [Apps, Extensions, VSCode]

What if there is an article that refers to a feature or concept present in both the “Ultimate VS Code Extension” and the “Ultimate Obsidian Plugin” – e.g. “Ultimate Concept”? One may want to tag this article with both Extensions tags. It will end up looking something like this:

• Tags
  • Apps
    • Obsidian
      • Extensions
        • Ultimate Concept [Apps, Extensions, Extensions, Obsidian, VSCode]
        • Ultimate Obsidian Plugin [Apps, Extensions, Obsidian]
    • VSCode
      • Extensions
        • Ultimate Concept [Apps, Extensions, Extensions, Obsidian, VSCode]
        • Ultimate VS Code Extension [Apps, Extensions, VSCode]

While the Tags hierarchy would be correct and look great, the tags (as listed in the Info Pane or the Tags Bar) would be unintuitive and very difficult to manage.

I propose a simple solution to these issues: show the tags hierarchy in full in the Info Pane and the Tags Bar. For example:

Ultimate Concept [Apps/Obsidian/Extensions, Apps/VSCode/Extensions]

Then, allow the user to edit the text within each of the hierarchical tags, if needed. After the text is edited, the corresponding tag can be parsed and resolved accordingly (e.g. creating a new tags hierarchy, or referring to an existing one).

I think this would eliminate a lot of confusion for DT users. I’ve searched the forum for posts referring to nested tags, and there are quite a few that show that these issues affect many DT users, and that there is quite a bit of confusion about how nested tags work.

[chrillek]

@rcarlan

The above example may seem farfetched to some. So, here’s a more relatable example:

Why not do it the other way around:

• Extensions
  • Obsidian
  • VSCode

Perhaps you could also find another way to achieve what you want. Deeply nested tags are probably not the best choice. You could also use differently colored tag hierarchies:

@rcarlan

I think this would eliminate a lot of confusion for DT users

Only for those using tag hierarchies with identically-named tags buried deep down in them

[meowky]

@rcarlan

One may want to tag this article with both Extensions tags.

I see this scenario as a hint that you should dissociate the Extension tag from any particular AppName. Neither one is subordinated to the other. If such scenarios occur often with your other tags, it could be a sign that you’re using more tags than you should.

[Silverstone]

I use only groups as tags, because it gives me the needed level of automation, so that management efforts would cost less than the effect from this management, i.e. not to fall into micromanagement muda. In my practice I didn’t find such a place for ordinary tags, so I don’t use them

[rkaplan]

Agreed - Groups are much less likely to result in confusion or mis-assignment when a misclassification could be mission critical.

That said- if the original poster wants to continue with a complex nesting structure such as this then i would suggest the best way to resolve it would be to eliminate the duplicate names at the source.

Thus instead of

• Tags
  • Apps
    • Obsidian
      • Extensions
    • VSCode
      • Extensions

I suggest

• Tags
  • Apps
    • Obsidian
      • Extensions - Obsidian
    • VSCode
      • Extensions - VSCode

That seems to me to be a much simpler solution and which meets the stated goals if tags are to be used.

[BLUEFROG]

That is correct. You should not use redundant tags. This is discussed in several places, most notably the Getting Started > Tagging > Nested Tags section of the built-in Help and manual as well as this blog post…

DEVONtechnologies | How to Use Nested Tags