remove "nested" tag does not remove inherited tag.


one question about tagging:

I have a tag “read” to mark pdf files that I have to read thoroughly (and annotate) later.
This tag “read later” is contained in another tag (group) named “action” to group all the tags which contain something I have to do (e. g. “buy book” or “get article in library”…).

So if I tag a pdf with “read later” it automatically “inherits” the tag “action”, which makes sense.

However, If I now remove the tag “read later” from the document in the info window, the document still keeps the “action” tag, which does not make sense, as this was not implicitly assigned but “only inherited”.

I know, I know - that would not happen with a flat tag structure, …
Is there a way to distinguish tags which were directly assigned and those inherited by assigning other “sub-tags”?

I just thought I’d have discovered a difference between groups and tags, but I tried it and with groups it is the same:

I created a group named “supergroup” and in this group another group “subgroup”.

If I replicate a document into “subgroup” it get both grey tags for “subgroup” and “supergroup”.
If now I remove the tag (by deleting it with backspace in the Information window), the replicate moves to the “supergroup” and it keeps this tag which originally was “only inherited”.

Situation is different when I select the item in three pane view (or another one) and then send it to the trash.
Then, it seems to also loose the connection with the inherited tags/groups…

That’s tricky IMHO, because the behavior of the app is in a way logical, but in another way inconsistent…

a practical question:
is there a way to remove a certain tag (e. g. “read later”) and all tags containing it (in my example “actions”) from the selected item(s) by AppleScript?

kind regards


The way tags were created doesn’t matter. Therefore you have to remove both tags from the Info panel or Tags bar.

I believe that the way this is done is predictable, and consistent, but I do understand how it might not appear so initially. If I assign a nested tag (or folder group), I am indicating that I want to assign all inherited tags to the document-this you know already. However, if I remove the nested tag, that does not necessarily mean that I want to remove the parent, inherited tag. I am indicating that I want to promote the document to the level of the parent. This makes sense when I nest tags for nouns under other tags for nouns, not so much so when I nest tags for verbs. The tags ‘action’ and ‘read later’ are both verb tags-remove the child tag and there is still a verb tag assigned.

If you have nested noun tags, then rarely is this a problem. If you want to keep the ‘action’ tag to search on, then don’t nest other tags under it. If you are only using the ‘action’ tag to organize various actions, then disable the ‘actions’ group from tagging using the Info pane. You can have ordinary, non-tagged, groups under the master Tags group. Then when you remove the ‘read later’ tag, the document backs out completely from the hierarchy-it does not move up to the ‘actions’ group as is the case when ‘actions’ was a tag.

None, other than they will appear right-to-left in the tag bar/Info pane to mimic the tag hierarchy. In other words, if you assign a flat tag, a nested tag, and another flat tag, the tags will appear as ‘FlatA’ ‘Parent’ ‘Nested’ ‘FlatB’. I rarely nest tags, but the ones that I do nest have a naming convention that immediately indicates the parent-child relationship. As example, I have a tag ‘research’ that has nested tags ‘researchKM’ (knowledge management research), 'researchLM (learning management research), etc. Note also the naming convention-I don’t name the KM tag ‘KMresearch’ as a) I want all my research tags grouped together in the Tag view and b) I want the tags to be easily recalled. When I begin entering ‘rea’ in the tag field, I am proposed all the research tags to pick from.

Both logical and consistent IMHO, because the first example (deleting the tag) is the means to remove only that one tag. The second example (removing the document) is the means of removing all tags from the document. Without the option for the second example, it would be a tedious process to remove a nested tag, back up to the next level, remove the next nested tag, etc.

I’m not sure if this is what you are looking for, but when working with nested tags, I open the lowest tag subgroup in the 3-pane-view (in your case: “read later”) and delete the items there, instead of deleting the tags from the items. This will remove all inherited tags (“actions”), too. I never place items directly in tag groups, so they won’t get deleted that way.

thanks, Christian and Greg for your comments.
@Greg: “consistent” it is, now that I know the difference between the two methods to remove tags…


Not exactly.
I was hoping for an apple script which does that without having the tag open in 3-pane-view (or another view).

I’m searching for an “automated” way which I can execute with an AppleScript e. g. to remove the “read later” tag (and all its parents) when the pdf file (or whatever it is) is open in a separate DTPro window or is selected in any view in DTPo.

I don’t want to have to jump to the tag each time…