all items should contain a "citation key" field

[simon]

for use with BibTeX export and key-based citation formats

[dstillman]

Hmm, would this include attachments and notes (which currently have no interface for modifying fields)?

[dstillman]

Also, is this the best way to go about this? It seems the request, at least in terms of BibTeX, is generally to be able to customize the algorithm for key generation, not necessarily to be able to (or to have to) assign a particular key to each item individually.

We could implement this in a similar way to the attachment file renaming feature, where you can specify a format string that pulls in the fields you specify--it's currently limited to only a few fields plus the ability to specify the maximum length of a field, but if it supported more/all fields it might work for this too.

That wouldn't address the (less frequent) request of retaining BibTeX keys, but it seems those are usually generated from some amalgamation of the fields anyway, so the ability to use a format string might be sufficient.

Are there other cases (other than for BibTex) where we'd need this field?

[karnesky]

Sorry for the bugspam--wrong field:

I don't think attachments and notes need to be modified--there aren't multiple "legacy" formats that rely on a user-assigned identifier.

Customization of the algorithm would be an improvement. However (as you point out), having a "citation key" field seems to be the only way to reliably roundtrip data that is imported with citation keys.

BibTeX is the most commonly used citation format that relies on identifiers. However, OO.o's current citation database relies on them. And local IDs are used by the endnote and RIS tagged formats, so there might be other third party apps that make use of them.

[dstillman]

But would such a field be useful if it was actually used for multiple types of identifiers? Then if you imported another type of file and tried to export those items, you'd get EndNote local IDs for your BibTeX keys. For that matter, even importing someone else's BibTeX file and having their keys be exported might be annoying, especially until Zotero has batch editing support to let you clear a field on multiple items at once.

How would a customizable generation format work in combination with this field? I guess the option to use the format string for either all items or just items without existing keys? You then still have the issues above, though...

[karnesky]

One possible design would be to bundle this feature up with a more generic identifier field, which would allow the assignment of multiple global and local ids (DOI, PMID, OCLC, ISBN, arXiv, url, etc.) to a single record. It could then have separate local IDs for EndNote, BibTeX, etc.

However, this might be over-engineered. There probably isn't strong demand to keep the EndNote and BibTeX IDs differentiated. They have similar technical limitations (short, mostly ASCII strings) & translation between the formats is relatively easy (especially when the LaTeX/BibTeX transcoding nuances are needed for the other fields of a BibTeX export anyway). VERY few users would probably use a different ID depending on what format they were exporting. So, different local IDs (like Endnote) are no different than BibTeX keys & the only question is whether to retain the ID or to regenerate it.

There is a question of when the local ID should be assigned automatically. It might be assigned:

1. on import
2. through some user action (on selected items, for example) during normal operation
3. on export

I agree that (1) might benefit from an advanced setting could be to have the local ID retained or generated on the import of an item with an ID. I do not know what the better default would be (there have been complaints both about the particular scheme of auto-generation & that the ID isn't retained on import in the forums).

(2) probably needs batch support to be tenable if it was the only choice. However, it may be the best compromise (it retain keys by default, but allows for regeneration accourding the the preferred scheme). This is the way that JabRef works.

(3) is too late to retain the way that keys were generated for dups (assuming a number or letter is appended to the key, as is typically done). But it might be least intrusive to users who don't need the keys and/or who actively disdain them. (The same advanced setting described in (1) could apply here if (3) is the only scheme.)

I think (2) is the best long-term solution. The current implementation is closest to (3). Depending on the timeframe for batch editing, and the level of demand for better BibTeX key support, one might wait for batch editing or improve (3) (with a user-defined naming scheming & a setting for whether to apply it to all records or only unlabeled records).

[bdarcus]

FWIW, I think the ultimate solution to this problem ought to be resolved with a view towards Zotero 2.0. Put simply, do these keys figure in URIs, and if they do, how? What is their formal role in the data model?