Regarding the URL field in the Generic Inspector: is the value stored only in DEVONthink, or is there anything in a file or file metadata that is mapped to that field? More to the point: is there any property or value in a PDF file that I can directly write from outside of DEVONthink to set that URL value?
That is a DEVONthink-specific attribute.
OK, no problem. Thanks for confirming.
What are you trying to do?
On e.g. import/export DEVONthink reads/writes the URL to the extended filesystem attribute
com.apple.metadata:kMDItemWhereFroms. E.g. browsers add this attribute to downloads and some other apps can read this too.
If I understand your question correctly, you’d like to copy the URL into a PDF metadata field. In order to do so, you’d first need an application that is able to write PDFs. Preview comes to mind, but it’s AppleScript support is apparently fairly limited (or I’m overlooking something there, which is well possible).
PDFPen has AppleScript support to add to the PDF’s metadata. But it supports only a limited number of fields, and there’s no provision for URL data. So you’d have to tweak one of the available fields (author, title, keywords etc.) for your purpose.
I suppose that other apps like Adobes Acrobat Pro can be scripted to do that as well.
Here is the situation. I use the Zotero desktop application to manage my references and store PDFs of articles and books there. I use DEVONthink’s indexing facility on the Zotero storage folder to enable the use of DEVONthink’s awesome capabilities (search, annotation, smart rules, etc.) on the contents of my Zotero database. But this leads to a problem: when looking at a PDF file in DEVONthink, how do I find the Zotero database record that corresponds to it? I can search on the author and title (and was doing it that way), but it would be better to be able to go directly to the Zotero record.
To achieve this, I’ve been writing an application (Zowie) that recursively scans for PDF files in local Zotero storage folder, looks up the Zotero bibliographic record corresponding to each PDF file found, and write a Zotero “select” link into (depending on the user’s choice) the Finder comments and/or PDF metadata fields. (A Zotero select link has the form
zotero://select/... and when opened, causes the Zotero desktop application to open that item in your database.) Those different alternative methods of storing the Zotero select link can all be read by DEVONthink; a simple DEVONthink smart rule can be used to read the Zotero select link from each PDF file and write it into DEVONthink’s URL field for that file. Presto: I can use DEVONthink’s Data → Launch URL command and be taken straight to the Zotero entry.
While writing the code and looking for alternatives of where to write the Zotero select link, it occurred to me there’s a chance that DEVONthink’s URL field might actually correspond to something in a PDF file. If so, I could make Zowie write the Zotero link in the appropriate place in the PDF file, and that would eliminate the need for a DEVONthink smart rule to copy the URL.
That’s what prompted the original question.
@cgrunenberg I tested it and it works – this is excellent! It makes it possible to do what I wanted to do (c.f. the reply to Jim) in a more direct way. However, if I have already indexed some PDF files and set their
com.apple.metadata:kMDItemWhereFroms attribute from outside of DEVONthink, DEVONthink does not seem to update the URL field, even if I use File → Update Indexed Items. (It does pick the URL when I import a PDF file with the attribute set, and it also does it it if I index a file anew.)
Is there a way to make it happen for already indexed files?
Additional note 2020-11-29: in addition to the indexing question, I have another: by trial and error, I discovered that if the
com.apple.metadata:kMDItemWhereFroms value does not begin with ‘http’ then DEVONthink does not appear to update the URL field on import. Is that the case?
Only im-/exporting & indexing of items support this at the moment, updating of indexed items doesn’t. And only web links are used, other links are ignored.
@cgrunenberg Thank you so much for your reply.
If there is not a technical or security reason to exclude non-http values of
com.apple.metadata:kMDItemWhereFroms, I’d like to request removing the exclusion in a future version of DEVONthink. It’s not just for
zotero://select/... links; some other applications also use custom URI schemes (e.g., BibDesk).
Likewise, if there is an efficient way to detect metadata changes during indexing, it would (speaking selfishly) be great if DEVONthink would update the URL field.
In the end, I was able to get around the current limitations by adding
zotero://select/... links to the Finder comments, then using a DEVONthink smart rule with a short script to update the URL fields.
This is not terribly difficult, but it would be easier and more direct if setting the “Where from” metadata property on a file caused the DEVONthink URL field to be set directly.
The next release will support this.
Is this already supported? I have updated to 3.6.1 and it doesn’t seem to work, when importing the file. Or is that a different case?
This has been set by @mhucka’s great zowie tool!
If I drag and drop the file into my data base…
The URL field is not filled out - which was my expectation from following this thread.
I see. I will wait (im)patiently then.
(Thanks again for Zowie. My manual workflow had been moving files into Zotero to get a reference, rename the pdf, etc., then importing the pdf for storage (and removing it from Zotero) and finally linking the reference with the pdf, by adding an item link to Zotero and adding a reference link to DevonThink. Thanks to your tool I will be able to slash the manual steps needed here by at least a third. The rest is possibly automatable, too. But this gave me a big leg up.)
You’re welcome! I’m glad it’s useful for others. BTW, did you see my other posting announcing it and giving an example smart rule to copy the Zotero link from the Finder comments to the URL field?
I actually am using the comment field version atm.
@mhucka is correct. See the Release Notes for 3.6.1 (and they have info on all releases).