Smart zotero://select function for DOI

qqbb

I'm wondering whether the following zotero://select function with a smart DOI look-up has been considered. It might be useful in many ways. The function zotero://select/DOI/[id] should look up the local library for an item with DOI=[id]. If an item exists, it should be selected in Zotero (in case of duplicates, select the latest item). If not, https://dx.doi.org/[id] should be opened in the browser.

The link zotero://select/DOI/[id] would be a persistent link that works before and after an item has been added to the local library. It would work for all Zotero users. The function helps quickly finding an item in the local library, or importing it through the browser in case it doesn't exist yet. This helps avoiding duplicate items. It should also facilitate forward and reverse citations lookups, in case a list of DOIs can be obtained.

By default, zotero://select/DOI/[id] should look up the local library first. One might have a short form zotero://DOI/[id] for convenience and long forms to be specific about the location: zotero://select/library/DOI/[id] and zotero://select/groups/[groupID]/DOI/[id].

Similar functions might also be helpful for other identifiers. An analogous function could be used for the URL field. Then a local snapshot of a web page could be called through zotero://select/URL/[url]. I read that Citekeys are planned for Zotero proper, which would be great. Then, zotero://select/Citekey/[Citekey] should be very useful.

bwiernik

The problem with this is that multiple items might (correctly or incorrectly) have the same DOI or URL in the same library, or the same item might exist in multiple libraries. Which would such a link select in those cases?

adamsmith

The multiple items issue seems eminently manageable in a single library - items with identical identifiers would either all be selected (that'd seem like the obvious solution to me) or you use a convention such as selecting the last one like qqbb suggests. Across libraries is trickier, but the links could just default to My Library and require a group identifier to work in a specified group (which is kind of of the current item ID ones work).

There may be technical reasons not to do this: item IDs are special in that Zotero, under the hood, uses those to steer GUI operations, i.e. the Zotero select link directly mirrors what Zotero itself does. This is different from using other fields, where the Zotero select link would implicitly run an advanced search and return the results. Dan would have to say.

Going beyond that, creating links that can either behave as within application links _or_ link to a web resource seems a bit problematic to be from a UX (and potentially even a security) perspective, but I haven't thought that one through.

qqbb

As adamsmith writes, one could have the function only checking one location by default, e.g. My Library, and go to the web page if no item is found. In case multiple items are found, I would suggest to only select the most recently added one. Let me try to motivate this preference:

1. The most recently added DOI item has probably also been used most recently and is likely the more relevant version. The older version might e.g. be a preprint. It is also more likely that the most recent item will be identical to the version you would import this time. As bwiernik correctly noted, having multiple items with the same identifier can be intentional or unintentional. In the case of web pages etc., zotero://select/URL/[url] would point you to the most recent item in your collection. You might well want another snapshot of this page. Then you choose "view item online" and import again. The link gives you the option to review your most recent version before you do this.

2. A crucial point in my view is that the smart link should not be a function for managing duplicates. This might require a careful review of items, which you don't want to be forced to do while researching. Instead, the function should accelerate accessing/importing links, while avoiding to create unintentional duplicates. I would therefore prefer not to select all matching items in case of more than one match.

Let me give a (very) concrete example related to following up references in a paper. Say, you are reading this paper, which you have imported to Zotero. If you copy-paste the references from this web page to a Zotero note, you get a nicely formatted list with DOI-URL links for most references. These links point to the journal web pages and you can import items quickly from there. But you might not wish to import all >100 references. Next time you look up a reference, you open the URL and wonder whether you already added this item. Let's now assume zotero://DOI/[id] is working. You could edit the source of your Zotero note with the references and replace URLs of the form http://dx.doi.org/[id] with zotero://DOI/[id]. The links in your reference note will now point to your local item in case it exists and open the browser in case it doesn't. You will not lose time by accidentally importing the item twice and having to review the duplicates later. An Add-On might do this link conversion, i.e. "Zoteroize" links.

bwiernik

Your concern about duplicate items has been raised before, but it is a technically challenging problem to solve. Zotero:// select links aren’t widely used, and I don’t think these are a good mechanism for addressing duplicate item s.

qqbb

Thanks for your comment. I'm aware that dealing with duplicates is difficult. A general duplicate warning message for imports could be problematic (e.g. slowing down mass imports) and distracting (warning messages for false-positives). In my view the quick access/import feature of such a smart link would be more central.

dstillman

Going beyond that, creating links that can either behave as within application links _or_ link to a web resource seems a bit problematic to be from a UX (and potentially even a security) perspective, but I haven't thought that one through.

I don't think we'd have a zotero://select link do anything other than select an item in Zotero. Having that start resolving a DOI in your browser seems far out of scope.

But while I appreciate the detailed request, I'm also not particularly convinced by this. The example given seems pretty narrow, and the obvious alternative would be to just add some annotation (or even a regular zotero://select link) to the note to indicate that you saved the item. You could also just copy the DOI or title into the Zotero search bar if you didn't remember if you had saved it. And there are better possibilities for duplicate detection/prevention.

Since DOIs aren't human-readable anyway, this also wouldn't make zotero://select links any more transparent — you'd just be replacing a short identifier for a longer one.

qqbb

Thanks for your answer and sorry for my lengthy remarks. I accept the criticism that jumping to the browser in case of no matching item is not an option. Such an unpredictable behavior of the links might indeed be bad from a UX perspective. Let me restrict the discussion to a more conventional lookup function. Since it's not a proper select function anyway, let's call it zotero://lookup which might include some measures for reducing potential risks. The function could display a pop-up saying "no item found" in case of no match and have a flag to indicate which items to select in case of more than one match. Something of this sort: zotero://lookup/DOI/[id]?select=[all/newest]. There is already the Zotero lookup box "Add Item(s) by Identifier" for importing items based on their ISBN, DOI, PMID, arXiv ID. So, one might have zotero://lookup search for these IDs in the local library.

I agree that zotero://select already provides a great tool for linking items within Zotero and systemwide from other applications. The benefit of using DOIs etc. would be to provide an automatic or semiautomatic way for it. DOIs are ubiquitous, many recent pdf articles have clickable DOI-URLs. Instead of opening the item on the web, wouldn't it be great if these links directly pointed to your local Zotero item, which has your notes attached? Something similar could be achieved with "Zoteroized" reference lists (example above), with the link destination hidden just as in the pdf files. In a way, these links would be your local version of https://dx.doi.org/[id].

Let me give another example related to the interoperability of Zotero with other reference managers. Say, you receive a LaTeX paper draft from a co-worker with a .bib file which has items with DOIs. The items are mostly already in your Zotero collection, so importing the .bib file into Zotero would just create many duplicates. Many BibTeX managers have an option to look up an item on the web based on its DOI, requiring only a single keystroke. With zotero://lookup it should be straightforward to set up your BibTeX program such that the item can be quickly pulled out in Zotero, enabling you to immediately review your annotations. Such a Zotero link could prove useful in many cases, since it's a pretty basic situation that you have a DOI in some form and want to look it up in Zotero. The link would accelerate this process, such that a single click or keystroke could be enough to open the Zotero item.

adamsmith

At this point this just sounds like a request to make Zotero more accessible via CLI, which I generally agree with and which I think Dan has said they're considering (or even planning?).

I don't think that doing that all based on URIs is the way to go though. E.g. if you had a CLI interface with Zotero you could simply search for the DOI, return the ItemID and then return the zotero://select link, which provides you with significantly more power and flexibility (e.g. with that approach you could also just pull out the notes directly, open associated PDF files, etc. etc.).

emilianoeheyns

A CLI interface could be built using the built-in web server. I occasionally script Zotero this way from VSCode (https://github.com/retorquere/zotero-better-bibtex/tree/master/test/fixtures/debug-bridge), a similar way could be used to do CLI.

qqbb

@adamsmith I agree that a CLI for Zotero would be great and offer much more powerful options. But providing access to more complex Zotero operations seems quite involved to me. You might also want some way to have the CLI commands accessible e.g. from Zotero notes with linked reference lists (example above). I'm not asking for advanced search capabilities for a Zotero URI lookup tool, since this might quickly get more complex. Also, frequently used searches can already be saved and linked through zotero://select. Some of the additional functions which you proposed could be integrated into the query string of an URI lookup function:

Possible basic (1,2) and advanced (3,4) options for a zotero://lookup query string:
1. DOI=[id] : a single item identifier (ISBN, DOI, PMID, arXiv)
2. select=[all/newest] : selection flag in case of multiple matches
3. itemview=[open/collapsed] : item viewing option
4. open-pdf?page=[page] : option to open the primary pdf file, if one exists
For example:
zotero://lookup?DOI=[id]&select=[newest]&itemview=[open]&open-pdf?page=[page]

Such a function might be useful in cases when you get a large number of DOI-URLs, e.g. from zuphilip's Open Citations Plugin, which you then want to access locally within Zotero.

@emilianoeheyns I had a look at your "Better BibTeX Quick Copy" and was surprised to find out that zotero://select/items/@[citekey] already provides links to Zotero items by referring to their citekeys. Thanks a lot for this great BBT feature!

One minor comment on BBT Quick Copy. For me, with one library, "Select link (item ID)" is lacking the "0_" or "1_" prefix to the itemkey. Similarly, I need to add the prefix manually for "Org-mode (item ID)" links to make them work.

I'm now using two keyboard shortcuts, one for BBT Quick Copy's zotero://select/items/@[citekey] and one for Zutilo's "Copy select item links".

emilianoeheyns

@qqbb can you open an issue for that on https://github.com/retorquere/zotero-better-bibtex/issues/new?labels=question&template=Question.md ?

zuphilip

There already exist a Zotero CLI: https://github.com/jbaiter/zotero-cli