(I think that was schema
, not id
.)
In a word processor document, Zotero currently uses the numeric itemID for id
. But what we do there isn’t really relevant — we can adjust as necessary. We embed URIs in the document that we use to reliably link to items.
When exporting CSL-JSON generally, however, we use a URI for id
. While we don’t currently use that in any other way, it’s worth noting that, if id
became a user-editable citekey, there wouldn’t be a guaranteed-permanent reference back to the Zotero item from the CSL-JSON entry. That might be an argument for keeping id
as an application-provided identifier and adding a separate citekey
field that was meant to be exposed to the user.
This sort of depends on your view of the world:
-
In a BibTeX-based workflow (as I understand it), you basically make sure that the citation key is set before any export and never touch it again, so the citekey effectively functions as a permanent identifier.
-
If you view CSL-JSON as a data exchange format, a user-editable field, even if it’s semi-permanent, isn’t the same as an application-enforced identifier that’s guaranteed never to change.
-
If you view CSL-JSON as primarily focused on citations, a citekey field, even if user-editable, might make sense as the primary identifier, similar to BibTeX, and permanent linking to internal database entries is simply out of scope.
I don’t have a strong opinion on this. I’d be inclined to go with (2) on principle, but in Zotero we don’t recommend CSL-JSON as a recommended data exchange format beyond citation processing, and that’s not going to change, so (3) seems like a reasonable position.