Openmeta and indexed databases. Bug????

I think that the behavior in 3) and 5) below are bugs, but really am very confused by tagging in DevonThink.

Create an indexed database of a folder (so files have the “alias” arrow).

  1. Tag a document outside of DevonThink using OpenMeta. Synchronize. The tag is shown in DevonThink.

  2. Tag a document in DevonThink by typing a tag at the bottom of the screen. Look at the document in an OpenMeta-aware application. The DevonThink tag is also an OpenMeta tag.

  3. Tag a document in DevonThink by dragging it to a tag “folder”. The tag is not exported as an OpenMeta tag.

  4. Tag the document in 3 by typing a tag at the bottom. The tags in 3) and 4) are now both exported.

  5. Change the name of a tag. The OpenMeta tags are not changed. Type tags at the bottom of each document so affected. As you add new tags, the old tags are updated.

This is very frustrating as I now have a set of “internal” and “external” tags for 100’s of documents that are now out of sync, and I can’t figure out how to get them back in sync.

Thoughts?

Looks like a bug to me. I’ve never encountered it before, but then I never drag documents to a tag folder to tag them.

I do have an idea as to how you can get the tags back in sync. There may be an easier way, but the following is the first thing that comes to mind. You’ll need an OpenMeta application that allows you to delete OpenMeta tags to complete the final step.

  1. Create a dummy tag, say ‘aaaa’.

  2. Create a smart group for all documents in the database (Search in database, Kind is: any document).

  3. Create the following script. This script is not mine-someone posted it in the forums here and I’m too lazy this morning to go find who came up with it. This is a nice script to apply a tag to a group of documents that already have various tags assigned. I find it very useful to assign tags without dragging documents into tag groups. In other words, you can use this script in the future to keep your tags in sync until a fix for the problem is implemented.

tell application "DEVONthink Pro"
	activate
	try
		set this_selection to the selection
		if this_selection is {} then error "Please select some contents."
		
		--set theTags to name of every parent of current database whose tag type is ordinary tag
		set theTags to name of every tag group of current database
		
		set myTags to (choose from list theTags with prompt {"Choose tags to apply:"} default items "" with multiple selections allowed)
		
		repeat with this_item in this_selection
			if exists tags of this_item then
				set current_tags to the tags of this_item
				set new_tags to current_tags & myTags
			else
				set new_tags to myTags
			end if
			set the tags of this_item to new_tags
		end repeat
		
	on error error_message number error_number
		if the error_number is not -128 then
			try
				display alert "DEVONthink Pro" message error_message as warning
			on error number error_number
				if error_number is -1708 then display dialog error_message buttons {"OK"} default button 1
			end try
		end if
	end try
end tell

  1. Select a few documents in the database, run the script, and apply the ‘aaaa’ tag to ensure that the script does not blow away the tags in the database. It worked fine for me, but like anything YMMV.

  2. Confirm that the tag was successfully applied to the selected documents and if so, select all documents in the smart group and re-run the script. Note that it will take a while to run if you have a large number of documents in the database. If the ‘aaaa’ tag group is visible when you run the script, you’ll see the number of documents in the group increment while the script is running, and you’ll know it is finished when that number matches the number on the all documents smart group.

  3. Confirm that the tag ‘aaaa’ was successfully applied to all documents in the database. When you run the script, it will also write out all the ‘internal’ tags to OpenMeta.

  4. Delete the ‘aaaa’ tag, choosing to delete files only in database when you empty the trash.

At this point, all the tags internal and external will be in sync, but for the ‘aaaa’ tag that will still show up in your external tags. I don’t know what OpenMeta tag tool you use, but I use Punakea and I can manage tags and delete the ‘aaaa’ tag from the external tags, putting the internal and external tags in complete sync. Hope this helps.

Thanks Greg_Jones. I think I found an easier way to get everything in sync, using your ideas

I use Tags (I didn’t know about Punakea—perhaps I should play with it).

I just went into Tags, and selected every tagged file, and added the tag “aaa”. Then to DevonSync to Synchronize, and because each one of these files had been “touched”, DevonThink resynchronized the internal tags to match the external ones. Then it is just a matter of deleting “aaa” (using Tags), resynchronizing, and deleting all unused tags in DevonThink.

If I continue to use Tags to bulk-apply or change names of tags, then it looks like I shouldn’t have any problems.

Thanks for your help!

Hmm…

Certainly your method worked, but I wonder if your analysis is correct? If simply touching the modification date of the indexed files would trigger the writing of “dragged tags,” then a bash script should have the same effect:

But it doesn’t.

Maybe Christian could say something here about what’s going on?

Best, Charles

To answer my own question, I believe that touching the file doesn’t update the OpenMeta/Spotlight kMDItemOMUserTagTime:


Azonips:~/Desktop/Test/martin_john$ mdls 19580406-martin.pdf
kMDItemContentCreationDate     = 2010-03-10 11:57:35 -0500
kMDItemContentModificationDate = 2010-07-21 14:58:47 -0400
kMDItemContentType             = "com.adobe.pdf"
kMDItemContentTypeTree         = (
    "com.adobe.pdf",
    "public.data",
    "public.item",
    "public.composite-content",
    "public.content"
)
kMDItemDisplayName             = "19580406-martin.pdf"
kMDItemEncodingApplications    = (
    "image2pdf.c"
)
kMDItemFSContentChangeDate     = 2010-07-21 14:58:47 -0400
kMDItemFSCreationDate          = 2010-03-10 11:57:35 -0500
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 0
kMDItemFSHasCustomIcon         = 0
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = 0
kMDItemFSLabel                 = 0
kMDItemFSName                  = "19580406-martin.pdf"
kMDItemFSNodeCount             = 0
kMDItemFSOwnerGroupID          = 20
kMDItemFSOwnerUserID           = 501
kMDItemFSSize                  = 153731
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Portable Document Format (PDF)"
kMDItemLastUsedDate            = 2010-07-21 14:58:47 -0400
kMDItemNumberOfPages           = 1
kMDItemOMUserTags              = (
    dance,
    graham,
    "greek drama",
    clytemnestra
)
kMDItemOMUserTagTime           = 2010-07-21 13:35:35 -0400
kMDItemPageHeight              = 1002
kMDItemPageWidth               = 565
kMDItemSecurityMethod          = "None"
kMDItemUsedDates               = (
    "2010-03-10 00:00:00 -0500",
    "2010-07-21 00:00:00 -0400"
)
kMDItemVersion                 = "1.2"
kMDItemWhereFroms              = (
    "http://proquest.umi.com.ezproxy.gc.cuny.edu/pdf/d458e7ed9937aae76d6ca22f1fd8ac9f/1268242055//share3/pqimage/hnirs102/20100310115735399/26005/out.pdf",
    "http://proquest.umi.com.ezproxy.gc.cuny.edu/pqdweb?index=2&did=170410202&SrchMode=2&sid=2&Fmt=10&VInst=PROD&VType=PQD&RQT=309&VName=HNP&TS=1268240195&clientId=78910"
)
kOMUserTags                    = (
    dance,
    graham,
    "greek drama",
    clytemnestra
)

So even though the modification date of the file content has changed, the tags are stamped as having not changed. This is why Greg and the OP’s trick works.

So you’d have to write a “touch” command for the kMDItemOMUserTagTime x-attribute to get this to work cleanly.

Charles

But, besides the issue of the various “modified” dates, I wouldn’t want to “touch” all the files in a directory. I only want to affect the files that already have OpenMeta tags, which I can find in Tags easily.

Charles, thanks for the insight into some of the behind-the-scenes machinery on how this works. I find it fascinating to read about the details, but then I have to dip into my limited supply of bottled water from the River Lethe in order to free up space for other facts, more relevant to my day-to-day projects.

Cheers

Well, you could write some other type of script that would do what you wanted to…

You’re welcome alanterra! I find though that I’m confused by my own explanations. I can get DTPO to sync when I’ve added a dummy tag there, but can’t get the sync of dragged tags when I add the dummy in Tags.

Charles

You are synchronizing after adding the dummy tag in Tags? AFAICT, DevonThink synchronizes to OpenMeta automatically (or doesn’t, if you add the tag by dragging the document to the “tag folder”), but synchronizes from OpenMeta only on a cmd-opt-S.

Yeah, I should have been more precise:

  1. If I type a tag in DTPO it will sync “automatically” with Tags.

  2. If I type a tag in Tags, I need to sync in DTPO for it to show up there.

  3. In case 1, “dragged tags” are exported from DTPO for the documents I have typed tags into.

  4. In case 2, no “dragged tags” appear in Tags, only the typed tag (obviously).

Best, Charles

I knew this whole subject had a sense of deja vu about it:
http://www.devon-technologies.com/scripts/userforum/viewtopic.php?f=4&t=10308#p48329

OK-

Here’s a small Applescript that will touch all, or a selection of, records in DTPO in order to force synchronization of “dragged tags”:

http://vze26m98.net/devon/dtpo_tag_touch.zip

Seems to work as expected, but it’s still pretty fresh.

Backup your data!

HTH, Charles

One issue I have discovered with the above script concerns the following condition. With hierarchical tags:

The example above illustrates the tag “fred” applied to three records which are contained in the “Names” tag, and four records tagged “fred” that are contained in the tag “Testimony.”

If you run the script you get:

with all of the records tagged:

I’ll look into why this is the case…

Best wishes, Charles

I see that the above effect is due to the couple of places that tag data is expressed in the DEVONthink Pro dictionary, and the way I am approaching synchronization.

There is a “tags” element (which I am updating) that presents the tags of the record as a list of strings. This might look like:

There is also the parent relations that link records in a hierarchical fashion. This might look like:

In the case of the parent relation, the numeric identifier keeps the two tags distinct: 575085 is not the same as 534248, even thought they are both named “fred”.

But that’s not the case with the list of strings that make up the “tags” element. This is what I’m updating, and if I add “fred” to it via Applescript, it’s up to DEVONthink Pro to decide whether I meant parent id 575085 or 534248.

So the fix would be to somehow “touch” the parent relations of a record to get them to sync externally, and not the “tags” element. But given that “dragging tags” doesn’t trigger sync, I wonder whether touching the parent relations would do the trick?

Given the difficulty of scripting my above posited “fix,” it will be a while before I attempt it. So if you have tags that aren’t uniquely named, you may want to avoid my script.

Sorry! Charles