Query re Tagging/Groups >> identical names

DEVONthink Tips
1

Hello all,

Whereas I have been using Tagging over the past few years in all of my DBs - for a variety of reasons, just created a new INDEXED database, that contains many groups.

I also decided to give the “Groups as Tags” as go [Exclude Groups from Tagging unselected].

Can someone please advise on the following behaviour that I am seeing - and if it is supposed to work like this - what would an alternative be?

I have many groups called Committee A; Committee B; C D E F etc.

Under EACH of those, I have sub-groups for the years where work was done in those, i.e. 2010; 2011; 2012; 2013.
And inside each of those, further sub-groups.

By using the Tags as Groups, I then simply activated that option on those top two groups. That way, if I dove into the sub-groups, I would still see tag:Committee A and tag:2010 [or tag:Committee B and tag:2014], which is what I hoped for.

My “difficulty” comes in, when I jump to the “As Tags” view.

I thought that I would be able to use the As Tags view to quickly whittle down what I was looking for - by (for instance) selecting BOTH “Committee A” and “2013” (or “2012” or “2010”)…

But as can be guessed, the problem is that there are now numerous instances of “2010” and “2012” etc., so unless I select “Committee A” and the correct “2012” (that is a sub-group of it, as opposed to Committee B or E), I don’t get hits.

What I hoped would happen is that ALL tags/groups called “2011” or “2014”, irrespective of whether they were the child of Committee A or E or G, would be ‘treated’ the same/interchangeably for the purposes of the As Tags view – and they are not.

Would really appreciate some practical suggestions for how to work around the “year” issue. There are close to a hundred of them - so 1st prize would be not having to rename them… :neutral_face:

2

One option using either the Three Pane or Split View, would be to:

  1. Go to the regular (blue) tag group and create regular (blue) tags for all your years (2010, 2011, 2012,…)

  2. Go to the Tags view and command- or shift-click to select all the 2010 group (gray) tags

  3. Type command-shift-I to bring up the info pane for all the selected 2010 group (gray) tags

  4. In the tags field, type 2010 to assign the 2010 regular (blue) tag to all the selected groups

  5. Check the box to exclude all the selected groups from tagging, and you are done with the 2010 tags

  6. Repeat for the remaining years

Now all documents contained in all the respective date groups will be assigned the respective blue date tag. Command-clicking on “Committee A” (gray tag) and a blue date tag in the Tags view will get you what you are looking for. You will need to be aware that when you add new date groups in the future, you will need to modify the group/assign the date tag accordingly.

3

@Cassady, the issue you describe is the one I complained about when DT first came out with their use of “tags.” This was not the general definition of tags as used in other software such as photo organization apps. The problem is the use of hierarchical tags. Tags are just subsets of the universal set of all objects. Hierarchy is used to organize tags. For example, “Paris” can be a city or a person’s name (or other objects). We may designate “city” as metadata of an object whose tag is “Paris”, ane use it not as a tag but as a means of organizing tags. Or it could be used as a hierarchical parent/tag of “Paris”. Likewise “person” could be a parent tag for a female, Paris.

But there are two ways of handling the hierarchical organization. Define all non-leaves of a hierarchical tree as non-tags. Or use ancestors of a tag in such a tree as additional tags. BUT just because the city “Paris” is not a child of “name” should not mean there are multiple, different tags called “Paris”. In the end a tag “Paris” should reference all objects associated with the descriptor “Paris”. There could also be a hybred of the two organizations. Any non-leaf in the tree could be either a tag or descriptor. Using a flat tree for all tags can be a challenge if there are many of them. It is the only mathematically correct way of using tags as defined in many other domains. But a tree structure helps us better manage tags. (Such a situation was the basis of a programming assignment I used a number of times in my data structures classes.)

Greg’s proposal is a Kluge. But it’s probably the only solution for tag use in DT.

4

Greg – many thanks for explaining things in such a manner that even I was able to understand it!

This will work as I need it to, and maintain the structure of my indexed database, with relatively little effort.
Now that I’ve seen your suggestion, it’s kind of obvious - but I wasn’t seeing it - so appreciate the help!

Thanks for putting into words what has been floating around in my head for the past few days!

That being said – I am constantly fascinated by how much complexity lies just below the surface of something seemingly as ‘simple’ as tagging!

5

FWIW - rebuilding the DB now.

Initially, I could add a few ‘blue’ tags, but thereafter - nothing that I tried allowed it. All of them defaulted to the grey ones??! :neutral_face:

Will see if the rebuild does the trick.

[EDIT]: It did, thankfully.

Going to start afresh with all as normal groups, add the normal/blue tags to the year-subgroups, and will then start switching off the “exclude from tagging” individually, where needed.

Thanks again for the assistance.