 |
 |
I was so hoping someone would bring up position of MARC fields. Everything Kyle says is true -- and I would follow that up by saying, no one will care, even most catalogers. In fact, I wouldn't even resort the data to begin with -- outside of aesthetics, the sooner we can get away from prescribing some kind of magical meaning to field order (have you ever read the book on determining 5xx field order, I have -- it's depressing; again, who but a cataloger would know) we'll all be better off. :) --tr -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Kyle Banerjee Sent: Friday, September 12, 2014 12:44 PM To: [log in to unmask] Subject: Re: [CODE4LIB] ruby-marc: how to sort fields after append? On Fri, Sep 12, 2014 at 9:20 AM, Galen Charlton <[log in to unmask]> wrote: > ... > One caveat though -- at least in MARC21, re-sorting a MARC record > strictly by tag number can be incorrect for certain fields... This is absolutely true. In addition to the fields you mention, 4XX, 7XX, and 8XX are also not necessarily in numerical order even if most records contain them this way. There is no way to programatically determine the correct sort. While this may sound totally cosmetic, it sometimes has use implications. Depending on how the sort mechanism works, you could conceivably reorder fields with the same number in the wrong order. The original question was how to resort a MARC record after appending a field which appears to be a control number. I would think it preferable to iterate through the fields and place it in the correct position (I'm assuming it's not an 001) rather than append and sort. However, record quality is such a mixed bag nowadays and getting much worse that tag order is the least of the corruption issues. Besides, most displays normalize fields so heavily that these type of distinctions simply aren't supported anymore. kyle