Suggestion: Different default behavior when removing a tag

Hi,

I wanted to share some quick thoughts here on a default behavior, which I find a bit confusing based on my use of DevonThink. I guess this goes hand in hand with a suggestion to change this default behavior, unless there’s a serious flaw in my logic :slight_smile:

When adding a tag, which is nested under one or more parent tags, the higher-level tags are also added to the item. This makes intuitive sense, because if for example the tag “programming language X” is relevant for an item, then the parent tag “programming” should also apply.

Conversely, from my perspective if the tag “programming language X” is removed from an item, then this also implies that the “programming” tag should be removed more often than not. This is currently not reflected in DevonThink’s default behavior, since higher-level tags remain after removing the most specific tag.

This means that it is necessary to trace back the parent tags every time I remove a tag from an item, in order to also remove those. I find this a quite counterintuitive and suboptimal workflow based on how I use DevonThink. This is particularly true since there is no way to display tags in hierarchical order; if there are many tags on an item then identifying the tags to remove can be time-consuming.

I would be curious what others here think, or if I am maybe overlooking something.

From my perspective, no it wouldn’t make sense to remove the parent tags when a child tag is removed.
The child tag would be nested in a contextually related structure.

Per your example…

  • Programming
    • Apple
      - → AppleScript

If I remove the AppleScript tag, that doesn’t remove the context of a tagged file being an Apple-oriented programming language. In fact, I’d say that would be quite surprising (and IMHO undesirable) behavior if the parent tags were removed.

I suppose if you were tagging in looser contexts than this, it may make a difference. However, in that case I’d ask, “Why are you nesting tags then?!?” :slight_smile:

Hi @bluefrog and thank you for this explanation. I agree that it could make sense that the item keeps the “Programming” and “Apple” tags after the “AppleScript” tag is removed

But there are also counter-examples, like this one:

For the sake of argument, let’s say I have two tag groups set up like this…

  • Natural Sciences
    • Biology
      o → Evolution

… and like this:

  • Social Sciences
    • Anthropology
      o → Ecological Anthropology (defined as "the "study of cultural adaptations to environments")

Let’s say I come across some interesting quote in the book “Sapiens” by Yuval Noah Harari. I create a Markdown note with a link back to that page and copypaste the quote. I add my own thoughts and tag the note with “Evolution”.

However, I then realize that actually this insight is much more anthropological than related to biology. This is an example, where I would have to remove all tags. In my actual setup, this can often mean “tracing back” up to 6 levels of parent tags and removing each individually, since I have a pretty detailed tag hierarchy.

However, again, your example is valid as well. Clearly it’s a case by case issue.

I wonder if there could be a modifier key which, if pressed while removing a tag, would also remove all of the parent tags. This way the default behavior would keep parent tags, but it would also be possible to address the other scenario as described here.

But what about the case where a parent tag is “code” and has child tags “procedural” and “1960s” among others. If I tag an article with both these tags and later discover that 1960s is not correct, when I delete 1960s, I would not expect “code” or “procedural” to be removed as well.

2 Likes

Assuming it is not proper to keep both sets of tags, in this situation, wouldn’t you want to remove the parent “Natural Sciences” tag so all the child tags in turn would be removed?

That’s exactly right, this way all tags that are no longer needed would be removed. However, how would one easily identify the highest-level parent tag?

Here’s a screenshot of what the tags inspector might look like after adding just three tags:

Screenshot 2021-12-21 at 10.51.07

… which relates to another feature request from my side: A hierarchical tag order in the inspector would make it possible to more easily identify the highest-level tag and delete it.

Another helpful addition in this context would be to visually distinguish inherited tags from tags added by the user, as suggested by @benoit.pointet.

1 Like

Case in point? :grinning:

I already accepted this argument in my response to Bluefrog’s explanation.

So I’m not saying that it’s never necessary or useful to keep the parent tags, but rather that there are a significant number of scenarios, where it is necessary to remove them and that it’s currently not possible to address those efficiently.

You are using group tags here. That is distinctly different than what you’re referring to in the initial inquiry. Can you clarify?

It’s true that in the screenshot above some tags are group tags (and others actually are regular tags).

However, if they were not group tags this wouldn’t change anything in relation to this topic, would it? Whether we’re speaking of group tags or regular tags, to my knowledge upon removing the lowest-level tag the behavior is the same in DT.

If not, I’d appreciate a hint - feels like I may be about to learn something :slight_smile:

That thread made me start dreaming bigger again: Suggestion: Adding an ontology system, aside tags and groups. I made a separate thread to not “pollute” this one.