Feature Request: Inherent Tags

[yuki-tm]

Hello Novoid! I began using FileTags recently to replace an older sorting system I've been using for years. One of my favorite features in FileTags is the ability to use mutually exclusive tagging, which has made my life a whole lot easier.

That being said, I find myself seeking more efficiency in my workflow. I think an excellent way to achieve this would be through Inherent Tags, which would allow a single tag to imply other tags.

For example, suppose I wanted to tag a photograph with "dogs"; it could then be assumed that I also wanted to tag the photo with "animals". Another example would be "bacon", which could have the inherent tag "food". This would be an excellent way to apply multiple tags in half the effort, which is something important for my personal workflow.

I wouldn't claim to know how this could be implemented into your model, but I imagine it integrated in a similar way to how mutually exclusive tags currently exist. Perhaps inherent tags would be contained within brackets {dogs animals} or derive their meaning through a precursor (+dogs +animals) in the same line.

Naturally this only shaves off a few moments, but in the grand scheme it speeds things up considerably over long sessions. I'm curious to hear your thoughts either way, thanks for the tools!

[nbehrnd]

Complementary to Karl's talk at GLT18[1] did you read his blog post «My Folder Hierarchy»[2] -- with a note on the tree diagram? So if data are organized this way, file names are a combination /including/ both a time stamp .and. one /multiple tag(s) as two criteria, independent of each other. Note, not all data are equally well suited for this approach, either by design (e.g., software projects managed by git), or by personal preference. For clarification of the suggested finer and (in my perception) partially redundant granularity ```pseudo-python if tag in ["dogs", "cats", "sheep"] new_tag_set = {tag, "animals"} ``` Are you suggesting that in your case there are really many sub categories of "animals" (though Karl's suggest is don't /define/ too many tags, balanced by the example of the journalist) and eventually, do you want to retrieve all items tagged with `animals` /except/ those about `sheep` to yield only a sub set of hits? Of course, there is no fix limit /by the program/ how many tags you assign to a file, and the number of the tags assigned eventually used to build the tag tree is adjustable (filetags' `--tagtrees-depth`). With an example of a controlled vocabulary for chemistry by Wiley-VCH,[3] the typical approach here is to use a tag of low hierarchy (e.g., `Alloys`) /only/ instead of e.g., `Alloys` .and. its hypernym `Inorganic Chemistry`. In addition, a typical journal policy is to assign three to five tags (or keywords) to each publication file for its subsequent indexing in databases -- since there are anyway other meta data (author name, date of publication, etc.) to narrow a search. [1] https://www.youtube.com/watch?v=rckSVmYCH90 [2] https://karl-voit.at/folder-hierarchy/ [3] https://application.wiley-vch.de/vch/journals/keyword.php

[novoid]

I understand the advantages of a tag hierarchy, which is another term used for the feature request at hand.

However, if you think of filetags and its implementation, this simply is not possible to implement without a substantial complexity when you think of TagTrees and how they are generated. It's not impossible to implement, I just think that this adds the danger of introducing bad tagging habits from my point of view.

According to my tagging rules summarized on https://karl-voit.at/2022/01/29/How-to-Use-Tags/ I try to "keep tags on a general level". So if you combine this rule with the other rule "use as few tags as possible", I'd recommend to drop "dogs" and "bacon" and stick with "animals" and "food" instead because they do represent the more general level. Add the rest in the file name, if you want.

If you do want to add this level of complexity yourself: please, do fork my project(s) and drop me a line so that I may include your fork in my READMEs.