New Zotero Fields: orig fields as supported in biblatex.

johnbentley

Summary
-------

My suggestion is to make all the orig* fields supported by biblatex, especially origdate, native to Zotero.

Alternatively native Zotero support for custom fields would allow end users to enter orig* fields.

Detail
------

Biblatex supports some very useful fields starting with orig. Namely,

origdate
origlanguage
origlanguage
origpublisher
origtitle

These are found in (biblatex) package documentation (pdf) page 21, under Section 2.2.1 Data types, available from https://www.ctan.org/pkg/biblatex .

While biblatex supports these fields at the database level the packaged native styles don't yet do anything with them. However third party style creators are free to use them. And indeed biblatex-chicago is a third party style (wrapped in a package) which handles these fields well (I've only tested origdate, I assume the others are supported).

Above all origdate is very useful when working with texts that are hundreds of years old. You generally consult such texts via a contemporarily published copy.

So, for example, given a biblatex entry like ...

@incollection{hume_1975_enquiry,
origdate = {1751},
date = {1975-06-12},
author = {Hume, David},
title = {An Enquiry Concerning the Principles of Morals},
booktitle = {Enquiries Concerning Human Understanding and
Concerning the Principles of Morals},
editor = {Selby-Bigge, L. A. and Nidditch, P. H.},
annotation = {Selby-Bigge and Nidditch’s 1975 edition is
based off a collection of Hume’s essays postumously
published in 1777. Hume’s ‘‘An Equiry Concerning the
Principles of Morals" was first published in 1751.},
publisher = {Oxford University Press},
location = {New York},
edition = {3},
isbn = {978-0-19-824536-0}
}


... and using biblatex-chicago in your preamble like this ...

\usgepackage[authordate,
backend=biber,
sorting=nyt,
backref=true,
alldates=iso8601,
cmsdate=on,
annotation=true]{biblatex-chicago}


... we can get a bibliographic entry as follows, one that displays origdate (1751) and the contemporary date (1975-06-12) ...

David Hume. 1751. “An Enquiry Concerning the Principles of Morals.”
In Enquiries Concerning Human Understanding and Concerning the Principles of Morals, 3rd ed., edited by L. A. Selby-Bigge and P. H. Nidditch.
New York: Oxford University Press, 1975-06-12. isbn: 978-0-19-824536-0

... and a citation like (with cmsdate=on)

Lorem blah (Hume 1751, 179).

or, (with cmsdate=both) ...

Lorem blah (Hume [1751] 1975, 179).

With the Zotero Add-in, Zotero Better Bib(La)Tex, custom fields can be created by leveraging Zotero's "extra" field. Therefore fields that Biblatex supports but Zotero doesn't natively export to, such as `origdate` and `shorthand`, can be entered in the extra field like this ...

biblatex[origdate=1751;shorthand=PoM]



Edit: Grammar.
Edit: Added alternative suggestion about custom fields.
Edit: Moved conclusion to top of post.

adamsmith

we'll definitely be adding original date; a little less certain on the others (I'd say, in descending order of likelihood, title, publisher, language). For a controlled vocabulary, GUI-based project like Zotero, just adding on more and more fields has more costs than for BibLaTeX, which is a text only format. It also requires adding support in the citation style language.

emilianoeheyns

BBT (as per usual) is a little cheeky and will split off a leading year-in-brackets to origdate for BibLaTeX.

CSL already has support for the following though:

* original-publisher
* original-publisher-place
* original-title
* original-date
* original-author

emilianoeheyns

As a matter of fact, I think if you use something like

{:original-date: 1751}

it will be picked up by both BBT and the built-in citeproc (meaning it should turn up in Word etc). This is a quirk of citeproc.js though -- not a documented feature as far as I recall, which means either citeproc.js or Zotero could independently legitimately decide to axe it at any given moment.

johnbentley

Thanks Adam. Yeah, personally I'm so far only interested in origdate. So your priorities happen to match mine in this regard.

Yes adjusting the vocabulary in Zotero is relatively costly, given that it has to translate to multiple vocabularies. But that might speak in favour of supporting custom fields. So a user, perhaps in conjunction with a specific custom translation developer, could at least use Zotero without needing Zotero to support the field natively.

In my case Zotero Better BibLaTex provides, more or less, the custom field extensibility I need.

emilianoeheyns, thanks for the tips. That prompted me to clean up a bit of the wiki at Zotero Better BibLaTex > Add your own BibLaTeX fields (I essentially added headings and somewhitespace).