@awood on Teams 2021-11-08 re: recent ingest
We pulled the records for three OCLC symbols from WC--FLARE, UIUSP, IULSP. Each loads their holdings to WC via the MARC LHR file method. I don't believe the 583$f or 583$a are validated for consistency. There were typos in both of these fields that require cleanup when the file is output. We should try to catch these on the way into PAPR, so the PAPR data is consistent.
Can we implement checks/corrections on these subfields during validation?
@nflorin on Teams: We can definitely implement checks, and some corrections.
583-A should be straightforward -- there are only 3 valid values, and we can:
change the subfield to whatever is closest of the three valid values
raise an error flag if the subfield isn't close to any of them.
In the 583-F we could do something like
find the dominant program name in a single institution's data
set everything to that value.
This would fail if there is more than one value per institution per loading file, which I can't imagine happening. The result of the check would be that either all of them are correct or all are wrong (if the majority were entered incorrectly). I think either outcome is OK.
@awood on Teams 2021-11-08 re: recent ingest We pulled the records for three OCLC symbols from WC--FLARE, UIUSP, IULSP. Each loads their holdings to WC via the MARC LHR file method. I don't believe the 583$f or 583$a are validated for consistency. There were typos in both of these fields that require cleanup when the file is output. We should try to catch these on the way into PAPR, so the PAPR data is consistent.
Can we implement checks/corrections on these subfields during validation?
@nflorin on Teams: We can definitely implement checks, and some corrections. 583-A should be straightforward -- there are only 3 valid values, and we can:
In the 583-F we could do something like