Tagging hierarchy confusion

Hi,

I am a little confused about the tagging hierarchy system in DT Pro. I have an example. I have a tag called ‘culture’, which is applied to 5 notes, and another tag called ‘American’ applied to one note. I drag the ‘American’ tag onto the culture tag so that it is under it in the hierarchy, and the single note I have with the tag ‘American’ inherits the ‘culture’ tag as well. Like so…

When I click on the ‘culture’ tag in the hierarchy I would like it to display all 6 notes, including the one with the ‘American’ tag, but it doesn’t - it only displays the other 5 notes with the ‘culture’ tag:

Strangely I have one or two other nested tags where the notes with the child tags do also display when I click on the parent tag, which only adds to the confusion.

Could someone illuminate me?

Thanks,

Nick

Tags work like groups, from the perspective of how DEVONthink’s views show you information. So, if you are in three pane view (as shown in your image) selecting a parent group will not show the content of the child groups. Here’s an illustration of the options:

Could you post an example?

Thanks for your swift reply korm.

I think I understand how DT handles tags - for me it would be preferable if, when highlighted, parent tags show all notes that have this tag, including child tags, rather than only showing notes that don’t have child tags.

The exception to the rule is that I have one parent tag which is showing notes with child tags when highlighted (the behaviour I would like), and I don’t understand why:

As you can hopefully see from the image above - the parent tag ‘Buddhism’ is highlighted, and notes with the child tag ‘absorption states’ are included in the list of notes, even though the child tag is not itself highlighted.

If you use View > as Tags and click on a parent (“Buddhism”) you’ll see a composite list of the documents with that parent tag and documents that have child tags of that parent. The boolean selection logic differs between those two views. Three Pane view ANDs parents and children. Tags view ORs them. (And I might have inverted that explanation :confused: )

I see. Not sure why. Do you happen to have more than one instance of the “absorption states” tag?

Completely off topic – how did you set up the coral selection highlight with the gradient effect?

Deleted … Incorrect

Actually, it is possible. Taking the view shown in the image you most recently posted, above – the one showing a document that has the tags “Buddhism” and “absorption states”, click on the downward-pointing arrow next to the tag “absorption states” in the tag bar of the selected document. Choose “Reveal Tag”, and DEVONthink will navigate to the location in the Tags hierarchy where that instance of “absorption states” is located.

It is also possible to have multiple tags with the same name, in a single layer hierarchy. Here is a database with only 3 tags, each named ‘2014’, and the single document has been assigned all 3 tags.

I’ve never seen this to be the case. In my experience, the order of how the tags are assigned is irrelevant. Additionally, if there is a tag hierarchy, assigning the parent tag(s) is unnecessary. Given the hierarchy colours->shades, the user only needs to assign the tag ‘shades’ to also have the document inherit the tag ‘colours’.

One other though about tag hierarchy is that if the hierarchy is ever changed, the tags change even if they were originally assigned manually by the user. That is, if I have colours->shades, and I manually assign ‘colours’ and ‘shades’ to the document, the document will have both tags. If I later move the ‘shades’ tag to the same level as ‘colours’ in the hierarchy, the document will drop the ‘colours’ tag.

Same thing happens if the user has assigned tags to a regular group. Move a document into a group with assigned tags, the document will inherit said tags. Remove a document from the group, and the document will drop the assigned tags, even if the tags had originally been added to the document by the user prior to moving the document to the group.

Thanks for these replies. I am learning more about tags by the minute.

korm, I am not sure how I managed to get the “coral selection highlight with the gradient effect” - not by design that’s for sure and I haven’t been able to replicate it.

I have double checked and I don’t have a second “absorption states” tag. I even deleted the tag, made sure there was no tag by that name in the tags view and then readded it as a child tag to the “Buddhism” tag, and still the same behaviour. It’s not a big deal - it’s the only tag I see behaving this way.

One more question has emerged in my mind from this discussion and perhaps you can help with this here. If I have two child tags of the same name, and I add this tag to a note, how does DT decide which parent tag to add to the note to?

I have experimented a little, and it seems that DT adds all parent tags to the note, which is not what I want of course. Even if I add the parent tag first, and then the child tag, DT is still adding the other parent tag too, as you can see from this image:

I first created the hierarchy with tags a and a1 and then added the same child tag a2 to each parent tag. I created the note test 1 and manually added the tags a and a2 and DT automatically added the parent tag a1 as well, which is not what I want - I only wanted the tags I added.

As can also be seen in the screenshot there is no note showing in the a2 child tag under the parent tag a. Instead it shows under the parent tag a1, even though I manually added the tag a, not a1. Strange!

I’m unclear how DEVONthink assigns the tag, if there are two or more tags with the same name, but I can say that it’s a bad idea to have multiple tags with the same name because of what you are experiencing now. Same thing applies for Groups with the same name that have tagging enabled.

One additional interesting thing about tag behavior is that had you created a>a2, then a1, and then replicated the tag a2 under a1, tagging a document with a2 will result in having the document appear in a>a2 as well as a1>a2. This is the only way I know of to have two tags with the same name where the behavior when assigning said tag is consistent.

As an example of where this might be useful, if I have a business database where I need to track wholesale accounts and retail accounts, and one account falls into both categories.

Also, if at a later date the account tag changes, the user only needs to edit one instance of the tag. The name change is reflected in both locations.

Almost forgot this korm, the gradient is courtesy of Yosemite’s translucent windows, depending on one’s desktop image.

Just a question about tags to ‘keep it all in the family’ here:

What is the behavior of tags on previously tagged documents if you subsequently reorganize the single list of ‘parent’ tags into parent/child relationships?

Anything at all?

Anything to watch out for?

Thx.

Tags are (in most aspects) groups, so moving them around and into other groups should not affect the behavior. Unless you start duplicating and replicating tags then you’ll run into problems such as Greg described. You can even rename tags and all the documents that have that tag will have the renamed tag instead of the old tag.

(Cheap trick: duplicate a tag “yada” and you’ll get “yada copy”, then rename “yada copy” to “yada yada” and all of those documents will have two tags: “yada” “yada yada”.)

Thanks, Korm. And yada yada just took on new meaning.