record['856'] is defined to return the *first* 856 in the record, which, if you look at the documentation...er...ok. Which is not documented as such in MARC::Record (http://rubydoc.info/gems/marc/0.4.2/MARC/Record) To get them all, you need to do something like sixfifties = record.fields '650' # returns array of results Or, to iterate record.each_by_tag('650') do |f| puts f['u'] if f['u'] # print out a URL if we've got one end On Thu, May 19, 2011 at 1:16 PM, James Lecard <[log in to unmask]> wrote: > I'll dig in this one, thanks for this input Jonathan... I'm not so so > familiar with the library yet, I'll do some more debugging but in fact what > is happening is that I have no value with an access such as > record['856']['u'] field, while I get one for record['856']['q'] > And the marc you are seeing is copy/pasted from a marc editor gui, its not > the actual marc record, I edited it so that its data is not recognisable > (for confidentiality). > > James > > > 2011/5/19 Jonathan Rochkind <[log in to unmask]> > > > Now whether it _means_ what you want it to mean is another question, > yeah. > > As Andreas said, I don't think that particular example _ought_ to have > two > > 856's. > > > > But it ought to be perfectly parseable marc. > > > > If your 'patch' is to make ruby-marc combine those multiple 856's into > one > > -- that is not right, two seperate 856's are two seperate 856's, same as > any > > other marc field. Applying that patch would mess up ruby-marc, not fix > it. > > > > You need to be more specific about what you're doing and what you mean > > exactly by 'causing the ruby library to ignore it'. I wonder if you are > > just using the a method in ruby-marc which only returns the first field > > matching a given tag when there is more than one. > > > > > > > > > > On 5/19/2011 12:51 PM, Andreas Orphanides wrote: > > > >> 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. > >>> > >> > >> > -- Bill Dueber Library Systems Programmer University of Michigan Library