It’s not about not “cover”. it’s about causing implementation issues given existing uses of id. E.g., if, say, Mendeley uses a UUID for id that’s used for connecting citations to sources, it can’t just map it to citekey.
Edit: oh, I think I missed the question, which is: why should the citekey be available to CSL styles other than as a citekey? That’s because it’d greatly facilitate traveling between Word and plaintext applications. Has come up a number of times as a request: You could author in Word, then set the citations to citekey and easily convert to LaTeX.
Ok, that’s a good use case. It could be possible to do the conversion with pandoc, and extract even the citations with some filter trickery. @retorquere has written a pandoc lua filter that goes the opposite way: produce a word file with linked zotero citations from a markdown source with pandoc style citations. So maybee …
Let’s say we added citekey as a variable for use in style, what would that mean for CSL JSON export? Will that citekey variable replace `id or will we have both variables?
Zotero’s CSL JSON current exports the item URI as id. Only BBT’s CSL JSON uses the citekey. I think leaving that to implementers (i.e. Emiliano and Zotero) is perfectly fine; I don’t see why we would need to prescribe this either way.
edit: I guess what we do want to prescribe is that they have both and they can but needn’t be identical?
Additionally, BBTs Better CSL exporters replace the id with the citekey, but I don’t touch the CSL as it moves through zotero, except for that hidden Pref above, and I don’t touch the standard CSL export.
Zotero and Mendeley both use their own “uri” field to manage items in document. Dan Stillman recently commented somewhere that they really only include an “id” field because it is required by spec.
(I haven’t checked out Mendeley’s new citation plugin, but I’d be surprised if this had changed.)
pandoc and citation.js seem to be the major consumers of the id field. pandoc treats it as a citekey.
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.
I guess in my view, I mainly see CSL-JSON as filling a similar role as a .bib file for BibTeX.
An option could be to add a citekey variable to the CSL-JSON spec, with the indication that it could be used to in the same manner as a BibTeX citekey with id as a fallback if citekey is unavailable.
That would involve primarily minor changes with two players:
pandoc adding citekey as primary source for the citation key. This would be easy enough as existing documents relying on id would still work.
citation.js switching citation-label to citekey, which they should anyway.
But what about a label style that prints the citekey as the label? That key then needs to be unique within the document.
I think this is something we should explicitly not do. Showing the citekey in the document is the realm of un-rendering a citation back into its raw identifier. That’s not a label style ala DIN 1950. If anything, it would a separate recommended API to produce a cite placeholder ala that used by pandoc or Sebastian/Frank’s ODF Scan plug-in for Zotero.
+1 for me on this — this seems like the most pragmatic approach to me with very little downsides. Also agree with the 2nd part – that’s why we have citation-label as a separate variable.
It seems we have some sort a consensus here. I’'ll add an issue to the schema repo issue tracker with @bwiernik’s idea.
We can still discuss details there, but I want to make sure this doesn’t gets lost.