Folder of Tags or Tags of Tags

I think it could be very helpful to allow organizing tags by folder in the tag pane. For example, the user could have “Actions”, “Work”, and “Personal”.

This is different from the Bear-like Nested tags suggestion in that the user does the organizing at the tag pane level rather than from inside their note. So a user could use just #todo everywhere, but have it grouped in the tag pane under an “Actions” folder.

Tag folders and Bear-like “Nested tags” would work fine with each other. Nested tag roots could be placeable under folders as well.

30 Likes

I would also suggest that tag could be placed in multiple folders to allow organizing them by different subjects. For example, the tag #note-system might be useful under both Work>Tools and Personal>Improvement.

6 Likes

this has been implemented

1 Like

In what version has this been implemented?
As far as I can tell, it has not.
The request is to nest tags into folders. (like Country>#Lebanon.
The implemented ‘nested tags’ feature does no such thing; it merely creates nested tags (#Country/Lebanon). In this scenario, there is no such tag as just #Lebanon.

1 Like

My apologies. I miseread this feature request. I will reopen it.

I wouldn’t call these tag folders, because tag folders are nested tags. It seems that you are describing tags of tags.

what I expect from this feature is grouping tag, without having nested. It’ll make easier to manage (having drag and drop to manage) and navigate tag. Just like file folder.

if each tag can be only in 1 group, it’s nested tags.
If each tag can be in multiple groups, it’s tags of tags.

1 Like

I see :+1:

I’m not sure how important this is, but I have to disagree with the nomenclature (I honestly don’t know what “tags of tags” means). But if tag ‘folder’ is to be used, then I think it should refer to the feature that is not implemented yet. Here is why:

The request is to have a ‘container’ that holds tags for organizational purposes but is not a tag itself, much like a folder is a container for notes, but is not a note itself.

Country
        #Canada
        #Lebanon

The tags are #Canada and #Lebanon. When viewing the tags in the tag pane, presumably one could sort as ‘nested’ and see them both appear under “Country”, or view them alphabetically and see them appear under C and L

In the implemented form, there is no container - the tags are just longer.

#Country/Canada
#Country/Lebanon

They may be displayed as though they are containers:
#Country
        Canada
        Lebanon

but the children are not tags. You can’t use #Canada, you have to use #Country/Canada. When viewing in the tag pane, they will always appear under “C” for Country.

1 Like

We can call it folder or group or any other name you like, however if there is a one-to-one correspondence, one tag in one folder, they are functionally equivalent to nested tags. The difference is syntactic.

Putting asade the one-to-one or one-to-many (tags of tags) difference, there is another big drawback for your proposal.

Where will these “folders” or “groups” be stored and where will the list of which tag belong to which folder stored ?
Not in the markdown files, you just want to write #canada. This information must be stored somewhere else in Obsidian. Making your notes dependant on Obsidian for this feature and not easily portable, or at least not easily undestandable outside obsidian.

One of the principle behind Obsidian is that your markdown files are “the source of truth” and there should be no extras (or as little as possible) that depends on Obsidian internal configuration/state.

1 Like

I would very much love tag containers only to avoid visual clutter in my tag pane, but I totally understand the storage problem described by WhiteNoise.

Lise also touched on a way this ties into another concept, the ability to use single tags in different parent/child combinations. I think this presents an alternative answer to the organization problem.

This is more an issue with how it’s handled in search than storage. If tag entry in notes remained the same, but search for a single string returned any matched tag segment tagging would essentially become a one-to-many approach. This could simplify tag entry, tag organization, and tag based search.

Consider the following structure:

#grandparent/parent/child/sister
#grandparent/parent/child/brother
#uncle/child/cousin
#aunt/child/cousin
#child
#child/sister
#child/brother

If I want to see all #child tags I have to do a combined search for 7 different tags. What I propose is in this case a search for #child should return results with any of those tags. Where a search for #sister or #cousin would only return 2.

The default click action could still search the full tag and therefore exclude other tags, keeping the essentially the same functionality, but adding options to use tags more flexibly.

4 Likes

@WhiteNoise, oddly enough that is one of the reasons why I want to keep my #Canada tag. No matter which program I’m using, I know that all my tags begin with # and I can always search for #Canada. I don’t have to remember that #Canada is now #country/canada or #places/canada or #cuisine/canada all because I wanted to organize my tags in Obsidian. If there is anything I would want to store in Obsidian and nowhere else it is precisely this sort of organizational ‘bonus’ thing where I could collapse my tags in the tree without affecting them. Just my preference.

1 Like

I agree.

There are definitely uses for tag folders for cases where you don’t want to use nested tags but want an evolving organization structure for easy access to certain tags when, for example, doing Ctrl clicks to build searches.

One possible workaround could be if Ctrl clicking multiple tags in sequence within a note had the same effect of doing so in Tag pane. I am trying to find if this request already exists.

Thanks.

2 Likes

Hi @WhiteNoise , I think I understand your concern from the design point of view. Would you perhaps consider having a folder/file inside the topmost Vault directory that is .vault_config/tag_folders that keeps the information in some json or yaml format?

I think eventually you will need to have some state configuration for higher level features and, although I understand you want to think carefully what you allow to work that way and keep it minimal, this feature might be worth the inclussion.

I agree. Keeping the tags simple (“#Canada” instead of “#Country/Canada”) would make them more portable. Tag folders, in the sense that Lise is talking about, would be a useful feature within Obsidian that would allow for organizing tags without changing them. It would be a good exception to the rule of portability – it would be fine to have the tag folders only be visible to Obsidian.

(For now, I am thinking of removing all the tag nesting that I have created, as the resulting long tag names create too much visual clutter.)

2 Likes

I also agree with the idea of leaving tags as plain tags and having the tag folders unique to obsidian so that on porting to another environment, only the tag folder aspect would be lost and that could be reimplemented in whatever environment you are transferring to. This makes a lot of sense imo!

Just writing to say I wholeheartedly agree with the idea of ‘tags of tags’, that is tags folder specific to Obsidian.
My current workaround for dealing with the mess of tags (and I’m new to Obsidian, so I might be wrong) is creating empty notes and using links to those notes instead of hashtags. This allows me to see the connections on the graph and see the back-links – but only in Obsidian.
To retain the ability to navigate (and thus connectivity) anywhere else, one’d have to manually re-type each note seen in the back-links list (as you can’t copy-paste from there), effectively manually creating a table of contents. So many and so granular tables of contents (created manually) were not my intention - that’s what hashtags are for, I (hesitantly) believe.

Like this? obsidian://show-plugin?id=obsidian-tagfolder

1 Like

You’re brilliant! :slight_smile: It seems to me like a combination of tagFolder and DataView plugins can do everything mentioned here (and more). Testing now.