Dates formatted as YYYY for Primo

[adehner]

The harvester is transforming dates from YYYY-MM-DD to YYYY and outputting them in dc:date for Primo.

As of today, this is visible in the following sets: The Academician (George Fox) Lewis & Clark Expedition: Nineteenth Century Newspapers (Lewis & Clark) Storyteller Photographs (Linfield) Gifford Photographic Collection (OSU)

The harvester specs and crosswalk do specify that the harvester should transform Digital Commons dates with month=01 AND day=01 (YYYY-01-01Thh:mm:ssTZD) to YYYY. But these are the only dates that should be simplified.

Please modify the harvester's date transformations to retain month and day values for Primo, with the exception of the Digital Commons case identified above.

@jallibunn

[ewg118]

For some reason, I thought I thought dc:date was supposed to be YYYY. It is, instead the ISO date with the '-' characters stripped, like the dc:date.start and .end. Are you sure you want this? dc:date is intended to be human readable, and isn't used for sorting or searching, correct? There are other ways to format date. See http://www.sixtree.com.au/articles/2013/formatting-dates-and-times-using-xslt-2.0-and-xpath/

[ewg118]

I'll close for now since the issue is resolved, but do let me know if you want to make dc:date more human-readable.

[adehner]

There are notes in the Primo norm rules column of "Crosswalks: DPLA MAP + Alliance DC + Primo PNX" (google sheet) which address if/how Primo norm rules will modify dates from the harvester OAI. These notes are mostly investigative, added as we explored Primo's limits. At that time we were concerned that Primo could only handle dates in YYYY format. Maybe you thought dc:date was supposed to be YYYY because of these notes.

Yes, you are correct that dc:date should absolutely be human-readable. The values the harvester is adding to dcterms:date for DPLA look great. And we would like these dcterms:date values to be used in dc:date for Primo. I hope this makes more sense.

[adehner]

So the hyphens should be preserved, as they are for DPLA's dcterms:date.

[ewg118]

Well, here's something to consider: Let's say a machine readable date is 1950-10-10. A web developer can modify the view for the HTML output to render this as "10 October 1950". The underlying LOD still contains 1950-10-10, for search and sort purposes, but the human still sees something a little cleaner. Do you want to keep the ISO8601 date in Primo (1950-10-10), or do you want the dc:date to display "10 October 1950" (or some other format)? I assume that Primo's UI scripts don't already contain a function to format an underlying machine-readable dc:date.

[adehner]

Your question is a good one. There is definite value in displaying dc:date in a more human readable format than YYYY-MM-DD, like Month DD, YYYY or DD Month YYYY.

The catch is that this is a UI decision that requires the input of more stakeholders. And more time for this conversation to take place. Sigh. So for the time being, we should stick with YYYY-MM-DD. If the Alliance decides to change the date format for digital resource records from the harvester, they can alter the XSLT at that point.

Thank you for raising these questions. I appreciate your perspective.

[ewg118]

I reverted back to YYYY-MM-DD

[adehner]

Thanks!