[Feature Request]: Remove Redundant Tags.

[NeedsLoomis]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• 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

[The-Stolas]

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.

[CyanVoxel]

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").