Closed nikdragovic closed 4 years ago
@bwatson78 and I just talked about how the citation builder should handle different cases of dates associated with objects. Here is the behavior we arrived at:
If an object has a date created and a date issued populated, then the date issued will be used in the citation.
If an object does NOT have a date created but has date issued populated, then the date issued will be used in the citation.
If an object has a date created and NOT a date issued, then the date created will be used in the citation.
If an object has NO date created (or it’s denoted as unknown with a XXXX value) and NO date issued populated, then the citation will not have any date.
For an example of a working document after correcting code, see id: 0687h44j62-cor.
During my investigation, I found that creator_tesim
s with numbers, parentheses, and/or brackets forced a parsing error and made the default citation fire. For future reference, the default citations adhere to the standards set forth on this site. None of them utilize italics or quotations, but most of the citations the Gem produces do. I noticed that when some fields are missing, the formatting of the default citation could use some work.
For example, this is the default citation created for 825x69p8kn-cor:
APA, 6th edition
Braddon, M. E. (Mary Elizabeth), 1835-1915. (1896)[Sons of fire, Stereotyped edition.]. Chester W. Topp collection of Victorian yellowbacks and paperbacks, Stuart A. Rose Manuscript, Archives, and Rare Book Library. https://digital.library.emory.edu/purl/825x69p8kn-cor.
The date in parentheses needs a space after it. There are a few more cases I can find, so this may become a common issue.
@bwatson78 I think this looks good for the scope of this ticket, but we should note the difference in how dates display in citations among these objects (which could be due to reasons you've already explained:
https://digital-test.library.emory.edu/catalog/0924b8gtj3-cor
https://digital-test.library.emory.edu/catalog/4300zpc86q-cor
https://digital-test.library.emory.edu/catalog/955m905qhd-cor
@nikdragovic I think I understand what you mean, but if this doesn't cover what you're referring to, please reply back.
Each of your listed examples above went through the citeproc gem (italics and quotations). I switched to a different field for more reliable results from the gem because, quite often, date_created_tesim
would have values like "1999?" and "XXXX". Since I need an integer (or a date string with the right formatting) for the gem, converting both to integers would return only one good value (1999) while leaving the "0ad" problem in place and much more frequent. I switched to year_created_isim
because it is never populated when date_created_tesim
sports "XXXX". The gem already has a way of delivering "unknown date" when it needs to (the "n.d." in "Robert Langmuir African American Photograph Collection, n.d. Box 28." in the Chicago citations).
The default citations still work with either the date_issued_tesim
or the human_readable_date_created_tesim
. Unfortunately, the citeproc gem only digests perfectly parsed date strings or 4 digit integer year values.
Thanks, @bwatson78! I just wasn't sure why the gem processed and inserted the first example as "unknown" for APA and MLA, but not for the latter examples. I think this makes sense; I should have checked against Curate.
Yeah, the first example is the default citation. For that document, the parentheses in the creator_tesim
forces an error in citeproc.
@nikdragovic can you provide feedback on when this is ready to be deployed to prod?
When the date_created is unknown (populated as XXXX in Curate), incorrect data displays in the citation builder, showing either 0AD or 0 C.E.
Acceptance Criteria
Example 1
Example 2