Address oai.samvera validation issues

[lthurston]

No description provided.

[amywieliczka]

I'm confused why there's so much happening in this mapper but there was so little happening in the legacy mapper: https://github.com/calisphere-legacy-harvester/dpla-ingestion/blob/cfe3dcb06008c0c6cb9d8207fe28bfaa1a855e4f/lib/mappers/ucsc_oai_mapper.py#L6 Are there things that should be happening in the base OAI mapper class that aren't???

[lthurston]

@christinklez @aturner @amywieliczka @barbarahui

I'm attaching a screenshot and a full CSV of the validation report from collection 154 after fixing a few things. There are some questions:

• Content mismatch on identifier: the uclamss_1387_* values don't show up in the vernacular, so this feels like data drift. I do see similar strings in filenames, but it would require transformation to generate these.
• Content mismatch on is_shown_at: URL domain was ursus.library.ucla.edu, now is digital.library.ucla.edu. I can write a validation rule to ignore this if that's helpful.
• Content mismatch on date: there are two date formats provided, mapping both seems correct to me, but I can modify the logic for this mapper if desired
• Content mismatch on subject: different order of list items

11-13-2023T21-54-23.csv

[aturner]

@lthurston In looking at what we've previously harvested from the old fetcher/mapper vs. Rikolti results, it looks like the first 3 items can be attributed to data drift.

UCLA has been migrating content across new systems, so the change to the item landing page/edm:isShownAt URL makes sense.

We are AOK with the multiple dates, and also the reordered subjects.

[amywieliczka]

Marking this as ready for review and merging as these updates make sense for a re-inventory of OAI mappers.