Conflicts between easykeys and betterbibtexkeys

[njbart]

zotxt’s “Easy Citekeys” are of the form DoeTitle2000 or doe:2000title, where title (IIRC) can be any word from the title.

If either of these two basic formats is used for BBT citekeys, too, pandoc-zotxt.lua will sometimes return unexpected items.

For example, if there are two items in Zotero, author and date of both “Doe, Jane” and ”2020”, one title “Foo bar baz”, the other “Baz”, I’ve had echo "@doe:2020baz" | pandoc -L pandoc-zotxt.lua -C -t plain sometimes return Doe, Jane. 2020. “Foo Bar Baz.” (Expected, of course: Doe, Jane. 2020. “Baz.”)

My temporary solution has been to modify the pandoc-zotxt.lua script, either disabling easykey, or moving it to the end of the relevant list, which seems to have the effect of checking the specific and (IIRC) guaranteed to be unique keys before the somewhat fuzzy easykeys:

ZOTXT_KEYTYPES = {
	'betterbibtexkey', -- Better BibTeX citation key
	'key',              -- Zotero item ID
	'easykey'         -- zotxt easy citekey}

I wonder whether it might be a good idea for the official pandoc-zotxt.lua to adopt this.

What’s more, my impression is that https://github.com/egh/zotxt has, sort of, retired easykeys in favour of betterbibtexkeys (at least easykeys are not being mentioned on the project’s main page any longer at all).

It might be worth checking with @egh, and if easykeys have indeed become obsolete, remove them from pandoc-zotxt.lua as well.

[odkr]

Thanks for reporting this. I'll have a look at it. zotxt may have changed the way it handles easy citekeys. I'm also under the impression that @egh has effectively retired them.

@egh, did you? I, for one, would be happy if you'd bring them back (the "you" indicating that I don't see myself finding the time to contribute a PR, sorry). Better BibTeX slows down Zotero's startup a lot. And there are only a few items in my library that are not uniquely identified by their author and the year they've been published in; I can take care of those manually.

As for trying Better BibTex keys before easy citekeys: Putting easykey last in ZOTXT_KEYTYPES may not do that reliably. If pandoc-zotxt.lua can't find an item that matches the given Better BibTeX key it will, eventually, try the same key as easy citekey, and if that works---which it might if the key has the structure <author>:<date><word from title>---, then pandoc-zotxt.lua will switch back to trying easy citekeys first. You can simply comment out the 'easykey' line to disable them completely.

[odkr]

Hmm, zotxt appears to handle queries that match multiple items the way it used to.

% curl 'http://localhost:23119/zotxt/items?easykey=haslanger:2012construction'
haslanger:2012construction returned multiple items%

However, easykey queries also work with titles of the form "DoeTitle2021". Could it be that you happen to have a Better BibTeX citation key that uniquely identifies an item other than the one it is the citation key of if you derive from it a search query for that author, date, and title keywords?

There is no way to dinstingusih easy citekeys and Better BibTeX keys, so pandoc-zotxt.lua simply tries whether assuming that a citation key is of a given type yields a result. It does so for every key type, and the order in which it tries them simply depends on whether assuming that a key is of a given type yielded a result the last time.

[njbart]

Could it be that you happen to have a Better BibTeX citation key that uniquely identifies an item other than the one it is the citation key of if you derive from it a search query for that author, date, and title keywords?

This, I think, is precisely what’s happening.

As to solutions, for me it’s perfectly ok to delete the easykey line from my local copy of the script. (So feel free to close this issue.)

One more general solution might be for pandoc-zotxt.lua to check whether BBT is running, and, if true, deactivate easykeys. If false, it might make sense to, in turn, deactivate betterbibtexkeys.

There might be other solutions, but I fould that checking whether BBT is running is possible by trying to fetch a bibliography without actually giving a collectionID, using curl http://127.0.0.1:23119/better-bibtex/collection. With BBT active, this returns Could not export bibliography: no path; otherwise No endpoint found.

Caveat: Replace portnumber 23119 with 24119 for Juris-M (see https://retorque.re/zotero-better-bibtex/exporting/pull/).

[egh]

I am trying to deprecate easykeys. I think BBT provides a much better solution. They are no longer mentioned in the documentation. I'm not planning to remove support from zotxt any time soon, though.

[odkr]

Hmm, disabling easy citekeys when BBT is installed would break old documents that still use them. I'm leaning towards just 'demoting' easy citekeys, so that they are only tried when the BBT citation key does not match, and making keytypes configurable, so that users have a better way to resolve conflicts than editing the souce.

[odkr]

I’ve released a new beta version that allows you to declare what type(s) of citation keys you want to use by setting a new metadata field zotero-citekey-types to the name of the citation key type that you want to use (or a list of such names). You can download it at https://github.com/odkr/pandoc-zotxt.lua/releases/tag/v1.1.0b3. Please give it a go and tell me what you think.

[odkr]

Closing this because v1.1.0b7 is stable enough. I'll release it once I am sure it will work with the next release of Pandoc.