Zotero place, series and seriesTitle fields

In the interest of simplicity, and with a view to possible data
exchange strategies, it seems to me that applications should adopt a
one-to-one mapping between their own native fields and CSL variables,
within any given item type. There are a couple of spots (described
below) where Zotero currently uses one-to-many or many-to-one
mappings, and I’m wondering how hairy it would be to get Zotero to
move to a pattern of uniform one-to-one mappings for Z-to-CSL
assignments (again, within each item type).

I’m thinking that this is something that would benefit CSL, as well,
by assuring that styles will be truly portable between different
systems that use CSL for rendering.

Here are the two problem cases:****
“place” -> event-place and publisher-place


The “place” field in Zotero maps to both event-place and
publisher-place in CSL. In style design, the dual assignment means
that a style for use with Zotero must use only one of these variables.
I’m not sure what Bibo does with these two “places”, but if CSL needs
to discriminate between them, I assume that Bibo and Zotero should do.
(If Bibo has only “place”, and CSL doesn’t need to discriminate them,
then perhaps they should be collapsed into a single variable in a
future CSL release.)


“series” and “seriesTitle” to collection-title


The story behind this one is is rather complicated, but the short
recommendation is that “series” and “seriesTitle” be merged into one
variable on Zotero-side (with a non-rendering variable to hold
overflow from entries where both are present). First, here’s a bit of
history:

Both “series” and “seriesTitle” were introduced into the DB schema
four years ago, back in the Scholar days, with svn #476. At that
time, CSL rendered only “seriesTitle”:

https://www.zotero.org/trac/browser/extension/trunk/schema.sql?rev=476
https://www.zotero.org/trac/browser/extension/trunk/chrome/chromeFiles/content/scholar/xpcom/cite.js?rev=474

A year later, after the Zotero launch, “series” was adopted as a
fallback for “seriesTitle”, and that remains the case today:

https://www.zotero.org/trac/browser/extension/branches/1.0/chrome/content/zotero/xpcom/cite.js?rev=1291

The fallback is significant for the journalArticle (article-journal)
item type, which accepts both values in the UI:

http://gsl-nagoya-u.net/http/pub/csl-fields/journalArticle.html

The mappings picture is complicated, with the assignment varying
between item types – and with Zotero “book” (which uses CSL book)
mapping collection-title from “series”, and Zotero “computerProgram”
(which also uses CSL book) mapping the same variable from
"seriesTitle". It’s kinda hard to follow.

The full list of assignments is as follows:


series

book (book)
bookSection (chapter)
dictionaryEntry (chapter)
encyclopediaArticle (chapter)
journalArticle (article-journal)


seriesTitle

audioRecording (song)
computerProgram (book)

  • journalArticle (article-journal)
    map (map)
    podcast (song)
    report (report)
    videoRecording (motion_picture)

It seems to me that using a single variable on Zotero-side (one of
"series" or “seriesTitle”, but not both) would make things much
simpler.

Frank

Here are the two problem cases:


“place” -> event-place and publisher-place


The “place” field in Zotero maps to both event-place and
publisher-place in CSL. In style design, the dual assignment means
that a style for use with Zotero must use only one of these variables.
I’m not sure what Bibo does with these two “places”, but if CSL needs
to discriminate between them, I assume that Bibo and Zotero should do.
(If Bibo has only “place”, and CSL doesn’t need to discriminate them,
then perhaps they should be collapsed into a single variable in a
future CSL release.)

The BIBO modeling is richer and more complex than either CSL or
Zotero. So there “place” characteristics are a property of a related
resource (say a publisher, or an event). CSL thus flattens that into
event-place and publisher-place (the hyphen in the CSL variable names
typically represent a relation).

In any case, I definitely agree with your suggestions (and that we
also need to talk about types).

Bruce