 |
 |
From the MARC documentation [1]: "Field 856 is repeated when the location data elements vary (the URL in subfield $u or subfields $a, $b, $d, when used). It is also repeated when more than one access method is used, different portions of the item are available electronically, mirror sites are recorded, different formats/resolutions with different URLs are indicated, and related items are recorded." So it looks like however the URL is handled, a single 856 field should be used to indicate the location [2]. I am not familiar enough with MARC to say how it "should" have been done, but it looks like $q and $u would probably be sufficient (if they're in the same line). However, since the field is repeatable, the parser shouldn't be choking on it, unless it's choking on it for a sophisticated reason (e.g., "These aren't the subfield tags I expect to be seeing"). It also looks like if $u is provided, the first subfield should indicate access method (in this case "4" for HTTP). Maybe that's what's causing the problem? [3] Anyway, I think having these two parts of the same URL data on separate lines is definitely Not Right, but I am not sure if it adds up to invalid MARC. -dre. [1] http://www.loc.gov/marc/bibliographic/bd856.html [2] I am not a cataloger. Don't hurt me. [3] I am not an expert on MARC ingest or on ruby-marc. I could be wrong. On 5/19/2011 12:37 PM, James Lecard wrote: > I'm using ruby-marc ruby parser (v.0.4.2) to parse some marc files I get > from a partner. > > The 856 field is splitted over 2 lines, causing the ruby library to ignore > it (I've patched it to overcome this issue) but I want to know if this kind > of marc is valid ? > > =LDR 00638nam 2200181uu 4500 > =001 cla-MldNA01 > =008 080101s2008\\\\\\\|||||||||||||||||fre|| > =040 \\$aMy Provider > =041 0\$afre > =245 10$aThis Subject > =260 \\$aParis$bJ. Doe$c2008 > =490 \\$aSome topic > =650 1\$aNarratif, Autre forme > =655 \7$abook$2lcsh > =752 \\$aA Place on earth > =776 \\$dParis: John Doe and Cie, 1973 > =856 \2$qtext/html > =856 \\$uhttp://www.this-link-will-not-be-retrieved-by-ruby-marc-library > > Thanks, > > James L.