If not, could you please consider making some (less important) fields available in all item type (e.g. archive, archive location, library catalogue, call number) so we can use these as custom fields?
Just hoping for custom columns/fields in Zotero sometime! For myself I would like to record both the date added to Zotero (which is already present) and the date I actually read the paper (in the custom column). "Date Modified" is also already present, but if I ever make any changes to the notes on a paper (which I do) then that throws this out the window...
FYI, I already use the "Extra" column for other purposes. Why just not have Extra1, Extra2, Extra3, Extra4, Extra5? A little clumsy but would be seriously helpful.
Translated title (usually the translation into English of a title in another language, required by English-language journals). Non-English abstract (the abstract in a language other than English when the English abstract is algo given) Translated author (transliteration, to be able to use either the author's Latin or non Latin name according to journal requirements) M/F (to register author's gender and analyze bias) Author address (email and affiliation for authos) Author OrcID Special issue title (in addition to series) Publisher address
I work with eighteenth-century books, many of which were published anonymously but for some of which the author was later determined. I need a custom field to indicate that authorship was attributed at some later date (Zotero doesn't play well with the standard convention for indicating attributed authorship, namely surrounding the author's name with square brackets).
Especially emonzo's suggestion of Translated title and Translated author fields!
Edit. Also Translitered title, Translated publication, Translated publisher, Translated Place. I write in three languages and now I have to create separate items for at least Japanese and English/Finnish, sometimes even all of them.
Would a custom field even help much for that? The citation processor (as it stands today) doesn't know what to do with non-standard fields, so it will ignore them.
Is there a good reason the keys in Extra’s key-value pairs must be valid CSL fields?
If that limitation were removed, these key-value pairs would effectively be custom fields, and custom CSL could access the keyed values just as it accesses DOI now. No?
My proposal for general key-value pairs wouldn’t offer everything we’d want from a user-interface standpoint, but it would allow us to store values and include them in citations and bibliographies.
@bwiernik, that is the case with conforming and portable CSL. But where is that enforced? Does citeproc really require it?
The style editor does not stop me from including in my custom CSL, say, <text variable="special1"/> Neither Zotero nor citeproc crash.
I assume citeproc looks in some associative array, finds no key, and happily keeps going. I doubt it even logs a warning. If it had found a value for that key, would it not have output that value?
Some code is parsing the key-value pairs in Extra and checking that the keys are CSL fields. What if that check was simply not performed?
Would I not then be able to write a local, custom CSL that uses my local, custom key-value pair?
Additionally it might help (me) if there was another Field labeled "Quality" or "Mark" - where one can enter 5-star or similar marking on an article. Using the "extra" field doesnt work well for that purpose :-(. I used such a field often in EndNote to quickly sort my articles into "good ones" with relevant info, and "bad ones" which are maybe not so important.
I would still love to have some custom fields that Zotero doesn't make use of as such, but which can be used by users (particularly in group libraries) for various purposes. For example, we've been adding IDs for Zenodo and OpenAlex into the extra field. We'd much rather have this in Custom01, Custom02, ... Or Extra01, Extra02, ... as suggested above. It's then up to users (in their user library) or for group members to decide how to use them.
+1 Some custom fields, would be amazing and super helpful. It's one of the main limitations of Zotero thus far (for me) .... and a Cover Flow or Cover/PDF Grid view.
> archive, archive location, library catalogue, call number
+1
I would be happy with a single field that doesn't wrap (like the toggle on abstract). If I put json into the callNumber, but because it wraps, it looks very ugly. So if e.g. callNumber had an option (like abstract) to not wrap, then this could be an option.
One could then make extensions that utilise that callNumber (and integrate into the UI). Depending on the length of data that can be stored in database fields, this would be very useful to us.
Obviously a custom field would be better, but I'd be happy with wrapping.
Incidentally - the motivation for wanting the custom fields is to store metadata that is often provided, such as ORCIDs / affiliations of authors, as well as citation graphs, additional IDs. It would obviously be good to have those
We would like to store other random stuff as well (say data from literature review and meta analysis), but to be fair, it's possible to attach this as a file attachment.
To be perfectly honest this is the single reason which has meant that I haven't (/can't) transfer over from my gnarly excel sheet to zotero which I have been wanting to do for a while now.
I agree with much of the above.* The ability to store arbitrary key-value pairs (aka custom fields) would be very valuable.
As mentioned above, Zotero does provide the "extra" field, but this is suboptimal for many reasons relating to both the user experience and data structure.
* I disagree with requests along these lines of "Why just not have Extra1, Extra2, Extra3, Extra4, Extra5?". High-quality software must not offer a hack when a sensible solution is readily available.
In response to "We would like to store other random stuff as well (say data from literature review and meta analysis), but to be fair, it's possible to attach this as a file attachment."...
Yes, it is _possible_, but Zotero can and should do better.* Allowing custom key-value pairs is a simple and elegant solution. (To be clear, "simple" does not always mean "easy" per the famous talk by Rich Hickey. Choosing "simple" instead of "easy" pays huge dividends over time because *unnecessary complexity* is minimized. Complexity has a way of *multiplying*; doing something in a non-elegant way often leads to related features being much harder -- and this complexity cascades, leading to a high cost of change.)
* Many programs (even a drawing app, OmniGraffle) offer custom key-value pairs!
Upgrade Storage
If not, could you please consider making some (less important) fields available in all item type (e.g. archive, archive location, library catalogue, call number) so we can use these as custom fields?
FYI, I already use the "Extra" column for other purposes. Why just not have Extra1, Extra2, Extra3, Extra4, Extra5? A little clumsy but would be seriously helpful.
Translated title (usually the translation into English of a title in another language, required by English-language journals).
Non-English abstract (the abstract in a language other than English when the English abstract is algo given)
Translated author (transliteration, to be able to use either the author's Latin or non Latin name according to journal requirements)
M/F (to register author's gender and analyze bias)
Author address (email and affiliation for authos)
Author OrcID
Special issue title (in addition to series)
Publisher address
I work with eighteenth-century books, many of which were published anonymously but for some of which the author was later determined. I need a custom field to indicate that authorship was attributed at some later date (Zotero doesn't play well with the standard convention for indicating attributed authorship, namely surrounding the author's name with square brackets).
Especially emonzo's suggestion of Translated title and Translated author fields!
Edit. Also Translitered title, Translated publication, Translated publisher, Translated Place. I write in three languages and now I have to create separate items for at least Japanese and English/Finnish, sometimes even all of them.
If that limitation were removed, these key-value pairs would effectively be custom fields, and custom CSL could access the keyed values just as it accesses DOI now. No?
Also, and Added By field so I can see who added the source would help me out a lot.
And I am guessing it would be easy to code in.
The style editor does not stop me from including in my custom CSL, say,
<text variable="special1"/> Neither Zotero nor citeproc crash.
I assume citeproc looks in some associative array, finds no key, and happily keeps going. I doubt it even logs a warning. If it had found a value for that key, would it not have output that value?
Some code is parsing the key-value pairs in Extra and checking that the keys are CSL fields. What if that check was simply not performed?
Would I not then be able to write a local, custom CSL that uses my local, custom key-value pair?
pleasethankyou ;)
tex.title=...to theextrafield if you have the better bibtex plugin.Additionally it might help (me) if there was another Field labeled "Quality" or "Mark" - where one can enter 5-star or similar marking on an article. Using the "extra" field doesnt work well for that purpose :-(.
I used such a field often in EndNote to quickly sort my articles into "good ones" with relevant info, and "bad ones" which are maybe not so important.
I would still love to have some custom fields that Zotero doesn't make use of as such, but which can be used by users (particularly in group libraries) for various purposes. For example, we've been adding IDs for Zenodo and OpenAlex into the extra field. We'd much rather have this in Custom01, Custom02, ... Or Extra01, Extra02, ... as suggested above. It's then up to users (in their user library) or for group members to decide how to use them.
It's one of the main limitations of Zotero thus far (for me) .... and a Cover Flow or Cover/PDF Grid view.
+1
I would be happy with a single field that doesn't wrap (like the toggle on abstract). If I put json into the callNumber, but because it wraps, it looks very ugly. So if e.g. callNumber had an option (like abstract) to not wrap, then this could be an option.
One could then make extensions that utilise that callNumber (and integrate into the UI). Depending on the length of data that can be stored in database fields, this would be very useful to us.
Obviously a custom field would be better, but I'd be happy with wrapping.
We would like to store other random stuff as well (say data from literature review and meta analysis), but to be fair, it's possible to attach this as a file attachment.
To be perfectly honest this is the single reason which has meant that I haven't (/can't) transfer over from my gnarly excel sheet to zotero which I have been wanting to do for a while now.
As mentioned above, Zotero does provide the "extra" field, but this is suboptimal for many reasons relating to both the user experience and data structure.
* I disagree with requests along these lines of "Why just not have Extra1, Extra2, Extra3, Extra4, Extra5?". High-quality software must not offer a hack when a sensible solution is readily available.
Yes, it is _possible_, but Zotero can and should do better.* Allowing custom key-value pairs is a simple and elegant solution. (To be clear, "simple" does not always mean "easy" per the famous talk by Rich Hickey. Choosing "simple" instead of "easy" pays huge dividends over time because *unnecessary complexity* is minimized. Complexity has a way of *multiplying*; doing something in a non-elegant way often leads to related features being much harder -- and this complexity cascades, leading to a high cost of change.)
* Many programs (even a drawing app, OmniGraffle) offer custom key-value pairs!