SRM fails to load valid MARC records due to 856 with no $u

Problem: If an 856 field does not have $u, instance creation will fail. The Instance expects a URI whenever there is an Electronic access accordion in an Instance. In MARC, it’s valid to have an 856 without $u and some libraries do use them.

Solution: To keep from causing Instance creation errors, I propose that 856s without $u should be suppressed from mapping into the Electronic access section of the Instance. Any 856s with $u would continue to map into that section of the Instance. Does anyone disagree?

See row 142 in the default mapping spreadsheet (FOLIJET Instance from MARC): https://docs.google.com/spreadsheets/d/11lGBiPoetHuC3u-onVVLN4Mj5KtVHqJaQe4RqCxgGzo/edit#gid=1871391984

Use attached 856 subfield u check.mrc file to check the updated Mappings

Examples

• MARC Record 1
  • 856 40$uhttp://ezproxy.lib.sample.edu.au/login?url=http://www.MONASH.eblib.com.AU/EBLWeb/patron/?target=patron&extendedid=P_1514248_0
  • In Instance, Electronic access info is created

• MARC Record 2
  • 856 40$uhttp://ezproxy.lib.sample.edu.au/login?url=http://www.MONASH.eblib.com.AU/EBLWeb/patron/?target=patron&extendedid=P_1593733_0
  • 856 4\$xhttp://resolver.library.cornell.edu/misc/abf5689$xhttp.//vet.cabweb.org/$xNo access to this journal via Vet CabWeb as of 7/29/02
  • In Instance, first 856 creates Electronic access info, second 856 (no $u) is ignored

• MARC Record 3
  • 856 4\$xhttp://resolver.library.cornell.edu/misc/abf5689$xhttp.//vet.cabweb.org/$xNo access to this journal via Vet CabWeb as of 7/29/02
  • In Instance, no Electronic access info created (no $u in 856)

• MARC Record 4
  • 856 40$uhttp://ezproxy.lib.sample.edu.au/login?url=www.jstor.org/stable/10.2307/j.ctt1xwfdw
  • In Instance, Electronic access info is created

=============================================================================

Background info from Anne Highsmith:
Source Record Manager rejects records that it considers to be invalid. It does not load the marc record into source record storage or create an instance record in inventory in these cases. Some of these rejections are invalid in the case of MARC records, because source record manager is trying to impose standards that are not valid in MARC records.

Example: SRM rejects a record that contains an 856 field that lacks subfield $u. Apparently, the underlying assumption is that if field 856 lacks a URL, then it must be invalid. This is not in keeping with the MARC standard, which allows 856 fields that do not have subfield $u.
Following xamples taken from LC MARC Documentation, http://www.loc.gov/marc/bibliographic/bd856.html
856 2#$aanthrax.micro.umn.edu$b128.101.95.23
856 1#$amaine.maine.edu$cMust be decompressed with PKUNZIP$fresource.zip
856 0#$akentvm.bitnet$facadlist file1$facadlist file2$facadlist file3
856 0#$auicvm.bitnet$fAN2$hListserv
856 2#$amadlab.sprl.umich.edu$nUniversity of Michigan Weather Underground$p3000
856 10$zFTP access to PostScript version includes groups of article files with .pdf extension$aftp.cdc.gov$d/pub/EIS/vol*no*/adobe$f*.pdf$lanonymous$qapplication/pdf