Clipping of 264$c removes useful information

[seanluyk]

Describe the bug In cases where the publication information recorded in 264$c contains anything other than digits, information about questionable dates, date errors and BC dates are not displayed. This information is useful to researchers. One of the index scripts is cleaning the dates in this field, which makes it possible to limit by date, etc.

To Reproduce See some of the following examples:

https://www.library.ualberta.ca/catalog/8343787 Should be: [2032 B.C. or 2031 B.C.?] https://www.library.ualberta.ca/catalog/8343785 Should be: [2043 B.C.?] https://www.library.ualberta.ca/catalog/1901116 Should be: 1957 [ie.1958]

Expected behavior

• This information should be displayed somewhere
• First date in the string should still be used for limiting/faceting

Additional context

• This is an issue with the source data, so may be difficult to deal with on the BL end
• Part of a larger issue of non-dates being in date fields

[ConnorSheremeta]

I see in the third example above that the publication year is in 260c (unlike the others where it is in 264c.) I just wanted to confirm with @redlibrarian that both fields, 260c and 264c, should be displayed here, comma separated if both fields exist

[weiweishi]

@redlibrarian I don't know if you've answered @ConnorSheremeta's question via another channel. Would you mind confirming if you'd like to display both 260c and 264c if they both exist? I don't know how likely this is to happen.

[theLinkResolver]

Has anyone from cataloguing provided useful/actionable information on how these fields work? @weiweishi's question suggests there's a gap, but I am trying not to speak out of turn anymore..

[weiweishi]

@theLinkResolver Thanks Scott. some explanation on how 260 and 264 are used in your practice would be helpful. I think in this particular case, we are wondering when 260c is used vs when 264c is used (some examples in Sean's request use 260c, while others use 264c). And we wonder if these fields/subfields can co-exist on the same record?

[theLinkResolver]

@weiweishi Great! Happy to help. I will write up something soon.

[theLinkResolver]

Why we have 2:

• 260 is a legacy/old way of recording publication, distribution, etc. and does not distinguish other functions
• 264 is the current way of recording this kind of information, and is designed to be able to distinguish five different functions (publication, copyright, distribution, production, manufacture)
• No record should have both 260 and 264

Repeatability:

• There may be multiple 260s or 264s in a record
• In rare occasions, there may be multiple occurrences of $c in the same 260/264 field - please disregard this due to its rarity

Multiple 260s:

• For things published in issues or parts, multiple 260 fields are used to show changes in publisher over time, as designated by $3
• Only one 260 is permitted to have a $c, and it will refer to the entire life of the publication

Example:

260 ## $3 July 2009-Jan. 2010: $a Denver : $b Smith Publishers, $c 2009-2013. 260 2# $3 Apr. 2010-<July 2010>: $a Denver : $b North Publishers 260 2# $3 <July 2011>- Jan. 2013: $a Minneapolis : $b Carl Publishers 260 3# $3 Apr. 2013-July 2013: $a Minneapolis : $b Hall Publishers

Multiple 264s:

• As with 260, the 264 (for a given function) is repeatable to show changes in publisher, etc. over time

Example:

264 #1 $3 July 2009-Jan. 2010: $a Denver : $b Smith Publishers, $c 2009-2013. 264 21 $3 Apr. 2010-<July 2010>: $a Denver : $b North Publishers 264 21 $3 <July 2011>- Jan. 2013: $a Minneapolis : $b Carl Publishers 264 31 $3 Apr. 2013-July 2013: $a Minneapolis : $b Hall Publishers

• The 264, itself, can repeat to show different functions (e.g. one for publication, one for copyright)

Example (ABC=publisher, Iverson=distributor; copyright date given):

264 #1$a[Place of publication not identified] : $bABC Publishers, $c2009. 264 #2$aSeattle : $bIverson Company 264 #4$a©2009

• Each function can have its own $c, but only one instance for each function

Distinguishing functions in 264:

• Second indicator is used for this: 0=Production, 1=Publication, 2=Distribution, 3=Manufacture, 4=Copyright
• Since we separate the 264c, we may want to think about what we call the field in display, with respect to the above
• Putting a comma between various dates will conflate them all as publication dates (except copyright and phonogram dates, which use the symbol)

260/264 $c vs. 008/07-14 dates:

• 260/264 is for humans, so it is appropriate to display it without modification
• 008/07-14 is for machines - this is what we should be using for faceting and sorting
• Since they have different functions, there is no hierarchy/preferred sequence, as previously suggested by Bib here: https://github.com/ualbertalib/discovery/issues/1037

[weiweishi]

Thank you very much @theLinkResolver This is very helpful information. @redlibrarian should we chat about where would be a logic location for us to keep track useful information as such, instead of letting it get buried in Github issues. Maybe we should create internal documentation to help us track the cataloguing rules that would have an impact on the Discovery system, which will become handy for any redevelopment work that might be needed.

[weiweishi]

And maybe we can grab a few minutes with @theLinkResolver to discuss the most appropriate mapping and labelling for the publication date used in the Discovery system so we can move this forward?

[abigailsparling]

To add a serials perspective, it would be a great improvement over the current display for the full 260/264 $c date data to be displayed, however, for serials 260/264 $c isn't always populated. Based on the stats I pulled, the 008/07-14 is more likely to have date information than the 260/264 $c. In an ideal world we'd use the 260/264 $c and if they're not present, then use the 008/07-14.

Here are our stats:

• 102,716 of 194,478 serial records with 260/264 present have $c date data
• 169,507 of 210,079 serial records with 008/07-14 dates have good date data (dates are not uuuuuuuu or uuuu9999)

[theLinkResolver]

@weiweishi Feel free to grab me for a meeting whenever you're needing to work through this. And @abigailsparling!!

@abigailsparling I confess I had forgotten about the option to omit pub dates for serials! Although the sentiment that 008 is for machines and 260/264 is for humans is still a point worth considering. Would we achieve something more appropriate and meaningful by displaying the 362(s)?