"Ghost" tag auto-complete suggestions - Clip to DTPO

DEVONthink Tips
1

Hello all,

Slight annoyance (enough to warrant me popping this up here) - hopefully someone can help!?

A few weeks back, I cleaned up my Tags. I consolidated tags that had jurisdiction identifiers in them, into 1 single tag, and then used a separate (new) tag for the jurisdiction.

The tags that were removed/deleted are gone, and no longer appear in the Tag view – or when I open the tag drop-down group in the 3-pane view. Similarly, when I enter new tags on the tag-bar, at the bottom of the screen, I do not get any auto-complete suggestions for those old tags.

However, when I use the Safari clip-to-DTPO applet, they make a re-appearance, as shown in my screen grab…

Ghost Tag suggestions.png

None of the last 3 tags ‘exist’ anymore, with them having been consolidated into the Legislation tag…

Any suggestions about how to clear them? Re-install the applet? Or is something else required?

Many thanks!

2

Is it possible that the tags are still in another open database, such as the Global Inbox?

3

Hi Greg!

Not from what I can see… Only 5 tags in my Global Inbox, and none of them have the ghost-tags as theirs…

I almost always only have 1 DB open at any given time - as was/is the case now - tried it again, same autocomplete options are offered… :unamused:

4

Are groups excluded from tagging, see File > Database Properties? And is the trash empty?

5

Yes to both of those. :neutral_face:

6

Are you able to find these groups/tags via Tools > Search and searching by name in all databases?

7

That worked! :blush:

I looked for them yesterday, but not with all my databases open. They are indeed in the Global Inbox. At some point in the past, I must have imported/copied items over to my “Test” DB, with those ‘old’ tags on, to run a few script tests??..

Could you please explain the following:

When I select the Global Inbox, with all of my DBs open - if I then go into Tag View, and ‘open’ the drop-down arrow next to Tags – I see a list of tags, that are all empty [as in - there is a zero next to them]. Clicking on them, reveals no files… The description of the Tag is also greyed out/faded…

What are these tags referring to? Can the simply be deleted? Not quite sure how they tie in with everything?.. :question:

8

As just a FYI, the tags were still in the Global Inbox yesterday, regardless of the open/closed status of your other databases. If you had no other databases open, you could add/delete content and tags to the Global Inbox, using it as you would any ‘regular’ database if desired.

It sounds like you are in the Split, or another, view rather than the Tags view, as the Tags view doesn’t have drop-down arrows and zeros to indicate empty tags, however that’s not what you are asking…

The behavior you are seeing is consistent for all databases, not just the Global Inbox. When you add content that already has tags, or you create new tags, then those tags are in the database forever, unless you delete them manually. When you delete all the documents with those tags, or in the case most common with the Global Inbox, move documents with tags to another database, the tags remain because…

The tags remain because DEVONthink anticipates that you will want to use these tags again in the future, so they are available and are auto-suggested when you begin to type to tag new documents. That’s how they tie in to everything, but if you don’t need them, they can be deleted.

I prefer to have the tags that are often common across databases available in the Global Inbox for consistency reasons. As example, if I have used the tag ‘video’ in databaseA and later want to add tags to documents in databaseB when databaseA is closed, I might type to create a new tag ‘videos’ instead. If the ‘video’ tag is already in the Global Inbox, it will be auto-suggested instead* and I won’t have to be concerned for searching across all databases for the ‘video’ and the ‘videos’ tag in the future, similar to what you experienced with the legislation tags.

  • Edited to clarify, this is what happens when adding tags to documents when using an external source such as Safari or the Sorter. If the user is tagging document in a specific (non-Global Inbox) database while in DEVONthink, tags from the Global Inbox and other open databases are not auto-suggested. However, the Global Inbox is different from the other databases in this respect. If the user is tagging documents in the Global Inbox, the tags from all open databases will be auto-suggested.
9

Thanks for the helpful reply Greg!

I realised that a.) I’m not using the Global Inbox nearly as effectively as what I possibly could be, and b.) I don’t actually understand how it works properly… :blush:

I have no idea, for instance, why I have tags “attributed” to the GI - since I try and work inside my databases only… It might be when I’ve used the Sorter or some other means of getting information in to DTPO…

If I might bother you or someone else(?) for an example of how tag-information etc. are populated inside the GI? If I can properly understand this aspect, will no doubt go a long way towards clarifying related questions…

10

I’ll see if I can clarify this, or at least give some ideas for further questions/discussion. Some of the following is pretty basic to DEVONthink, but including it helps me organize my thoughts and may be helpful to those newer to DEVONthink.

DEVONthink databases can contain tag groups (blue tags) that reside under the master Tags group in the database, and DEVONthink can have group tags (gray tags) if group tagging is enabled in the database properties. I’ll use the terms tag group and group tag below to distinguish between the two types of tags.

For all practical purposes, tag information is populated in all databases the same way, and the Global Inbox is a database. Tags can be added to a document in multiple ways before, or at, the time of import. Some of the more common means of doing this includes:

  • a document is tagged by the user when the document is added to a database (Sorter, Safari clipper, etc.)
  • a document already has tag information when added to the database (OS X Mavericks or later, OpenMeta tags)
  • DEVONthink adds tag information when the document is added to the database (convert categories to tags in RSS feeds, etc.)
    Let’s assume that in all scenarios below, I have added a document to the inbox of a database. How I have added it is irrelevant, but there is a a single OS X tag associated document. Once a document with tag information is added to a database, DEVONthink checks the document tags with the tags already in the database, and the ensuing process looks like this:

Are Group Tags turned ON for the database?
[list]-if yes, is there a group tag matching the document tag
[list]- if yes, then replicate the document to that group (document is in the inbox with a replicant in the group tag)

  • if no, then a tag group is created under Tags (document is in the inbox and is tagged in the tag group)[/list:u][/list:u]
    Are Group Tags turned OFF for the database?
    [list]-if yes, is there a tag group matching the document tag
    [list]-if yes, then increment the tag count of that tag group +1 (document is in the inbox and is tagged in the tag group)
  • if no, then a tag group is created under Tags (document is in the inbox and is tagged in the tag group)[/list:u][/list:u]

Now if we are to move the documents in the future, the main difference between tag groups (blue tags) and group tags (gray tags) in the database becomes apparent. Tags in the tag groups (blue) are associated with the document and are fixed in the database, while tags in the group tags (gray) are only associated with its group.

If a move a document with blue (tag group) tags from group to group in a database, those tags remain associated with the document. If I move that document from the source database to a target database, DEVONthink again applies the process described above, creating new tags in the target database as needed. The blue tag remains in the source database, even if there are no other documents in that database with that tag. This is why you are seeing the ghost tags in your Global Inbox. At some point, documents with the three old legislation tags touched the Global Inbox. Perhaps they were imported there, perhaps you used the Global Inbox as a temporary holding location (moving documents from databaseA to the Global Inbox, then moving them to databaseB), whatever, at some point they were in the Global Inbox. When they were moved out, or even deleted from the Global Inbox, the blue tags remain under the Tags group.

Now if a document with gray (group tag) tags is moved from group to group in the database, those tags do not remain associated with the document. Likewise, if that document is moved to another database, then the gray tags do not ‘tag’ along and no new gray tags are created in the target database, nor is the document automatically replicated to a group tag should there be one already in the target database. However, if the document contains blue tags in addition to gray tags, the blue tags will be evaluated as described above.

There is one more scenario that should be mentioned at this point, since I have already rambled on this far on tag behavior. It is possible to assign blue (tag group) tags to the groups in a database, regardless of if tagging is, or is not, enabled for the group itself. If I were to add a document to this group ‘Test’, it would inherit the gray tag ‘Test’ as well as the blue tags ‘DEVONthink’ and ‘DEVONagent’. However, the blue tags in this scenario are conditional-if I move the document out of Test, the document is no longer associated with the gray tag ‘Test’ nor is it associated with the blue tags ‘DEVONthink’ and ‘DEVONagent’.

Hope this helps, and wasn’t TMI for what you were wanting to know.

11

Greg - thank you for taking the time to put all this down - I’ve bookmarked the thread as a reference for later, should I have any other queries in future about tags! 8)

And I’m pretty sure someone will stumble across this going forward, and find it equally as useful! :smiley:

My usage scenario only sees blue tag groups being used, which is perfect since I seldom move files around - preferring to use the “replicate” option if I need to create a temporary group or such… Having said this, I did do a fair bit of jumping between my academic DB and Test DB in the initial stages - it must have been here, along with several imports into the GI, that saw the files in question ‘touch’ the GI, and see the Tags categories created…

I was quite frankly surprised by how many there are – but your explanation makes perfect sense, and I now have a good idea about how to clean things up…

What came through strongly about your post, was that it will help tremendously to think of the GI almost like a separate DB… It certainly makes more sense when I look at it like that!

With this being said, the last bit - quoted above - that’s the only part I’m still a little unclear on… That folder “Test” – is it a simple, ‘normal’ group that you created? You then add a document to it - and it is then associated with a grey tag [but that would surely be dependent on whether or not Group Tags is switched ON?]… If one then adds the blue tags (does it matter whether it is done through the Show Info menu/down in the tag-bar at the bottom of the document?) - I don’t quite understand how the blue-tags are then conditional to the document remaining in the group… :confused:

That last part [or rather, my understanding of the last part] seems to contradict what was said about them earlier – given how I thought blue tags would ‘remain fixed’ to a document, irrespective of how it is moved about?

12

The last part may indeed appear to contradict what was said earlier, which is why I wanted to mention it. Let me explain further.

Yes, it is a normal group in a database that has group tags turned ON, and thus it is associated with the gray tag that is the group name. If Group Tags are turned OFF in the database (the default behavior for all my databases-they were turned on in this database to illustrate the point), the behavior with the blue tags associated with the group is the same as mentioned above.

When adding tags to a document, it doesn’t matter if the tags are added to the Show Info pane of the document or the tag bar at the bottom of the document. Either way, the tag(s) are associated with the document.

However, if the tags are assigned to a group using the Show Info pane of the group, then the tags are associated with the group and documents will only display those particular blue tags when the document/replicant is in that group. Move the document from the group, then the tag(s) are dropped. The exception to this is if the documents already had some/all of the tags before the document was added to the group. If I drop a document with the ‘DEVONthink’ tag into the ‘Test’ group, it will now have both the ‘DEVONthink’ and the ‘DEVONagent’ tag. If I later remove that document from the ‘Test’ group, it will lose the tag ‘DEVONagent’ but keep the tag ‘DEVONthink’.

The non-permenant status of blue tags assigned to a group has been discussed before, and from what I was told the current behavior is what most users expect/prefer. Personally, I would like to see (perhaps as a database properties option) tags behave where if blue tags have been assigned to a document, then I have to do something (manual delete, script, etc.) to remove them. I subscribe to a lot of RSS feeds for research and I have tags assigned to these feeds for author, source of publication, field of interest, etc. Once the HTML feed document is moved out of the feed to a permanent location, that tag data is lost. What I currently do is copy all the tags in the tag bar, then move the document in the database, and then finally paste the tags back into the tag bar. Inconvenient, but it works.
I could also go into how useful I would find it to add tags to documents by assigning them to smart groups… And have a real tag cloud… And yada, yada, yada…

13

Greg - all sorts of pennies dropped reading through the above! :smiley:

Thanks again. I’m glad to say that I was mostly on the right track after all, but you’ve confirmed things now.

Pretty sure this will serve as a useful resource for other DTP newbies going forward… unless DTPO 3.0 goes and changes everything! :laughing: