[Feature Request]: Remove Redundant Tags.
Checklist
- [X] I am using an up-to-date version.
- [X] I have read the documentation.
- [X] I have searched existing issues.
Description
Currently, we can add a "Creature" tag to a file that already has a "Dog(Creature)" tag, which presents us with a meta challenge where we must organize our organizational system. Do we:
A) Embrace redundancy and include every valid tag. This is annoying because you'll have to dig into every tag's hierarchy to find and add the parents. Some will be missed making a mess and there can be quite the list of tags on a single file.
B) Only include the lowest level child tag we need. Clean, but difficult because there's no good way to keep in your head every possible parent and child when choosing tags, so some will be missed making a mess.
C) Some (arbitrary?) mix of both. Deal with an inconsistent organizational system.
Solution
One suggestion would be to change parent tags act as required tags. Have them be auto added if they don't already exist on the file. Basically switching from inheritance to composition. A Dog comes with a Critter tag, instead of a Dog tag is a Critter tag. You could then remove the () from the tags.
Alternatives
Perhaps don't allow adding parent tags if a child tag is present, maybe by filtering parents already on the object on the list of available tags, and removing parents already on the object when a child is added.
A simpler alternative would be to not allow adding parents at all. If your file is a shape, it HAS to be a circle, square, or some new tag. Clean, but limiting, and there would need to be a solution to orphaning tags when adding children to them.
Note
All of these, especially the alternatives, would greatly benefit from a UI update like https://github.com/TagStudioDev/TagStudio/issues/431
I agree, that the system would greatly benefit from either "parents as folders" functionality or a "child comes with a parent, but child isn't the parent" proposal that you described. The second one is particularly helpful for color organization, because the current system doesn't really work with it. In my library character tags are blue and fandoms are purple. But I cannot add "child-parent" to this structure, because it would just make all of them purple.
Perhaps if the second option is implemented, you can have the "Trim parents" feature as a manual option, which can scan and delete the repeating parents from each file in the library until a single instance of parent remains. I think a trimming system that requires a manual run is better, because it's a lot more clear to the user.
A separation of inheritance + composition style tags is planned for the future (likely 9.6+) to address some of the emergent messiness of using inheritance/parent subtags only. This has been something considered back and forth for a while but I believe the inclusion of both of these systems is a (relatively) simple way to address many issues with object description without resorting to a full-on RDF.
Currently (9.4), duplicate parents are currently consolidated during the search phase. I agree though that this doesn't make it clear to the user who is designing their tags as to which higher tags it may already inherit when trying to trace back the cause if it's inclusion in searches. I believe though that some UI element(s) might be sufficient to aide with this, for example a "tag traceback" list that can be viewed on any entry search result to see the full tag lineage of why it's included. Another more persistent idea is the ability to show all effective/"implied" tags, such as in #215. One more option could be an icon that displays next to subtags in the add/edit tag menu that signal that a base subtag is already contained in a parent (e.g. The tag "Motor Vehicle" on the tag "Honda Accord" may be considered redundant if "Honda Accord" already inherits from "Car" which inherits from "Motor Vehicle").
Checklist
- [x] I am using an up-to-date version.[x] I have read the documentation.[x] I have searched existing issues.
Description
Currently, we can add a "Creature" tag to a file that already has a "Dog(Creature)" tag, which presents us with a meta challenge where we must organize our organizational system. Do we:
A) Embrace redundancy and include every valid tag. This is annoying because you'll have to dig into every tag's hierarchy to find and add the parents. Some will be missed making a mess and there can be quite the list of tags on a single file.
B) Only include the lowest level child tag we need. Clean, but difficult because there's no good way to keep in your head every possible parent and child when choosing tags, so some will be missed making a mess.
C) Some (arbitrary?) mix of both. Deal with an inconsistent organizational system.
Solution
One suggestion would be to change parent tags act as required tags. Have them be auto added if they don't already exist on the file. Basically switching from inheritance to composition. A Dog comes with a Critter tag, instead of a Dog tag is a Critter tag. You could then remove the () from the tags.
Alternatives
Perhaps don't allow adding parent tags if a child tag is present, maybe by filtering parents already on the object on the list of available tags, and removing parents already on the object when a child is added.
A simpler alternative would be to not allow adding parents at all. If your file is a shape, it HAS to be a circle, square, or some new tag. Clean, but limiting, and there would need to be a solution to orphaning tags when adding children to them.
Note
All of these, especially the alternatives, would greatly benefit from a UI update like #431
I'm curious to know how adding or removing an extra parent tag for another tag should be handled. Let's that we have a tag A that has a tag B with the following file:
- File 1 [
A,B(added automatically by tagA)]
If a new C tag is added to the A either nothing happens or the tag C is added to the File 1:
- File 1 [
A,B(added automatically by tagA),C(added automatically by tagA)]
If then we remove the tag B either nothing happens again or the B tag is removed from the File 1:
- File 1 [
A,C(added automatically by tagA)]
This means that two approaches can be taken:
- Make parent tags an strict requirement for be able to use the child tag.
- Make "parent" tags more kinda a "Recommended" tag that are added only the first time you add the "child" tag.
Maybe both of this approaches can be taken by being able to tag a tag with "Required" and "Recommended" tags, btw this is similar how package managers like APT works.
Edit 1: As an alternative solution with an inheritance based system: It would be interesting to use a graph based representation of the tags kinda the Obsidian wikilink graph viewer, in this graph you would have tags with either an "active" border (blue?) or a "required only" border (white). You in this graph would be able to add to the file parent tags by clicking them (or maybe something like Alt+LMB).
Edit 2: Also I'm thinking that I may be interesting to have tags that can be called "Virtual"/"Grouping", these tags can only exists as the parent of another tag and cannot be used as an independent one.
An example of the usefulness of this would be having a Rating tag that has as children 1.0, 2.0, 3.0, etc; it make sense to be able to search for "all tags that have been rated", but at the same time it doesn't make sense to have a file with a Rating tag and zero proper number rating tag. This type of relationships would be more useful with the addition of mutually exclusive tags though.