Chicago Manual of Style (Note without Bibliography) (dev)

sean

Thanks to codec, erazlogo, and simon, this dev style is now available at http://zotero.org/styles

It looks very good so far, much improved over the existing CMS. Bugs I've noticed so far:

Ibid does not seem to be working. For example, I get
3. Senebier, “Considérations,” cxvii-cxviii.
4. Senebier, “Considérations,” cxiv
instead of
3. Senebier, “Considérations,” cxvii-cxviii.
4. Ibid., cxiv.

A book section in a work without an author or editor name displays an unnecessary comma after publicationTitle:
“Goust,” in Dictionnaire de l'Académie françoise, (Paris: Jean-Baptiste Coignard, 1694)
instead of
“Goust,” in Dictionnaire de l'Académie françoise (Paris: Jean-Baptiste Coignard, 1694)

Items published over several years with a date like 1751-1772 only display 1751, though this problem may be in cite.js, not in the CSL.

bdarcus

Items published over several years with a date like 1751-1772 only display 1751, though this problem may be in cite.js, not in the CSL.

The problem is a rather large one if you consider data portability. Usually when dates get encoded in a structured way (in RDF, relational databases, etc.), they are assumed to be a particular form, and to represent a single date. Among other things, this allows reliable sorting, repurposing for display, etc. In short, I'd hope to see some thought into how to deal with these funky dates in a standard way.

dstillman

In short, I'd hope to see some thought into how to deal with these funky dates in a standard way.

Well, Zotero does try to be fairly smart about dates while at the same time allowing flexibility of input. "Summer 2000", for example, will be parsed as 2000 for use in sorting and in the UI but will show up as "Summer 2000" in Chicago, which I imagine is the desired behavior. Standard dates can also be entered in the UI in various and sundry formats and will still be parsed correctly (verifiable via the "myd" indicator and the SQL date displayed on hover).

We mainly just need to add support for parsing ranges in Zotero.Date.strToDate() and then let the CSL engine reconstruct them in the proper format (since I imagine some styles might require "1751-1772" while others require "1751-72"). I think Elena has mentioned some weird date examples before that we'd have to take into account as well.

Codec

>"Summer 2000", for example, will be parsed as 2000 for use in sorting and in the UI but
> will show up as "Summer 2000" in Chicago, which I imagine is the desired behavior.

I'm not sure this is the case. When formatting the date for display in CSL, the only way it can be done is with something like

<date variable="issued">
<date-part name="month" suffix=" "/>
<date-part name="day" suffix=", "/>
<date-part name="year"/>
</date>

I'm not sure where "Summer" would appear in that, as it is already had to be split into D/M/Y. CSL does have a bucket called other for a date-part, but what is wanted here is something more like
<text variable="issued"/>
which I don't think is supported or allowed.

dstillman

Ah, well then, it may just be a fortuitous/incorrect fluke. I just glanced at the code, so Simon would have to comment. Should there be some mechanism for including dates like that in CSL? It's also necessary for things like "circa 1771".

dstillman

Here's the old message I was thinking about from Elena (from an off-list discussion):

in journal articles, the year is sometimes entered as yyyy-yyyy (as in Theodor W. Adorno, “On Jazz,” Discourse 12 (Fall-Winter 1989-1990), 45-69) For archival material, there also approximate dates (ca. 1204) or possible dates (1940? or [1940])

Another issue: BCE dates—would those be a problem? I asked my classics scholar friend about these—apparently in most cases scholars cite a contemporary print edition, with an editor and CE date but here a case when BCE dates are necessary, from his email:

'These images are important research resources:
http://www.papyrology.ox.ac.uk/POxy/monster/demo/Page1.html
There is a print version of this text, which needs to be cited by date, editor, etc. But the image of the original object is also very interesting and might well be used and cited as such. You’d treat this as an archival document; location, shelf-mark, etc. And the date would be an estimate, e.g. 2-3 c. BCE. This is the kind of information it would be very useful to have in a record of the image. I do it now with the info window, but you will surely have a better way to do this.'

Perhaps need to move this to the CSL list...

bdarcus

Well, Zotero does try to be fairly smart about dates while at the same time allowing flexibility of input. "Summer 2000", for example, will be parsed as 2000 for use in sorting and in the UI but will show up as "Summer 2000" in Chicago, which I imagine is the desired behavior.

But only because of your custom code. The dates aren't stored as dates in the database, and they're not encoded in a standard way in export formats. E.g. it's not standard.

It'd help to enumerate the key issues with dates (ranges, approximate, etc.) on the wiki so we could check later about handling them (in CSL, RDF, etc.). This effort at the DCMI might provide some help.

dstillman

The dates aren't stored as dates in the database, and they're not encoded in a standard way in export formats. E.g. it's not standard.

Actually all the dates are stored with the parsed date in SQL format in the database—for example, "November 30th, 2007" is stored as "2007-11-30 November 30th, 2007"—but this just lets us do SQL-based sorting of parsed dates. There's not much other reason to store any sort of encoded date in the database, since using it would still require string parsing, which we do already.

Some of the DCMI work looks interesting, and it'd be great if there was a parseable format that could describe many potential date strings for easier reuse, but as is we're not discarding any data—we're just passing it through to the output format the same way it came in.

But how dates are encoded in export formats is way off topic for this thread. Sean's issue is support for date ranges in CSL. Anyone can start a Trac wiki page on date issues if that'd help.

erazlogo

On the ibid issue--I'm on the road at the moment so can't fix this right away, but also I would be grateful if someone could point me to an existing style (new format) where ibid is properly coded and works correctly.

Codec

I think you're breaking new ground here - none of the styles I've done have required it, or else I've ignored/missed the cases where they do.
I might take a look later on if I get time, to see what's involved.

Codec

OK - the spurious comma, and the ibid stuff is fixed now I believe. Dates will have to remain for another day!

bdarcus

Actually all the dates are stored with the parsed date in SQL format in the database—for example, "November 30th, 2007" is stored as "2007-11-30 November 30th, 2007"—

I'm aware of that (and that's good!); I was referring more to the funky dates that are not of that form.

but this just lets us do SQL-based sorting of parsed dates. There's not much other reason to store any sort of encoded date in the database, since using it would still require string parsing, which we do already.

You're still thinking of your application; I'm interested in the integrity of the data that comes out of it. If I export a few MBs of RDF data, say, it'd be nice if I could work with it (say to do a SPARQL query and sort the results) without any special processing.

But how dates are encoded in export formats is way off topic for this thread. Sean's issue is support for date ranges in CSL.

Yes, but the way he wrote that request seemed to me to suggest a particular implementation. I just put that note there for the record.

sean

Thanks, Codec, for taking care of the comma and Ibid. Chicago output is looking great! I tweaked the CSL to add a period to Ibid. Forgive my ignorance on CSL, but why couldn't I add the period to the text term itself (i.e. text term="ibid.")? Instead I had to add suffix="." which works, but seems unnecessary, since Ibid. will always have the period. Erazlogo, if you're following this thread, could you make sure that the Chicago full note with bibliography style incorporates Codec's latest changes?

sean

Another extra comma, this time between author names:
2. Michael R. Gordon, and Stephen Farrell, “Iraq Lacks Plan on the Return of Refugees, Military Says,” The New York Times, November 30, 2007, http://www.nytimes.com/2007/11/30/world/middleeast/30refugees.html?_r=1&hp&oref=slogin
should be:
2. Michael R. Gordon and Stephen Farrell, “Iraq Lacks Plan on the Return of Refugees, Military Says,” The New York Times, November 30, 2007, http://www.nytimes.com/2007/11/30/world/middleeast/30refugees.html?_r=1&hp&oref=slogin

bdarcus

Forgive my ignorance on CSL, but why couldn't I add the period to the text term itself (i.e. text term="ibid.")? Instead I had to add suffix="." which works, but seems unnecessary, since Ibid. will always have the period.

The "term" is basically a localized variable. So it makes perfect sense that any punctuation would be specified outside the variable string. If you use "ibid." the software has no idea what to look for.

If one wanted to indicate that a term should by definition include a period, then it should be in the locale file.