 |
 |
On Jun 25, 2008, at 7:27 PM, Hahn, Harvey wrote: > Eric Lease Morgan wrote: > >> Who ever heard of an indicator being longer than two characters long? > > Byte 10 (zero origin) of the MARC leader specifies the number of > indicator characters. MARC21 and its predecessors have always > specified > 2, but the possible range is 0 to 9. The 24-character leader is the > "wizard" of MARC records, specifying what a particular version of > "MARC" > looks like. Libraries have always been very conservative in this > regard, using only a single set of specifications from 1968 to the > present. However, the standard actually permits a very wide range of > possible implementations. On Jun 26, 2008, at 5:41 AM, Tim Prettyman wrote: > On 6/25/08 4:55 PM, "Eric Lease Morgan" <[log in to unmask]> wrote: > >> Yep, I'm getting ALEPH output, and the issue is not so much whether >> or >> not alpha-named fields exist but whether or not my parsing tools >> (MARC::Batch and friends or Marc4J) handle them correctly. For >> example, MARC::Batch warns of invalid indicators with values such as >> " BE". Who ever heard of an indicator being longer than two >> characters long? > > You get the "invalid indicator" message with the FMT tag because > ALEPH uses > it as a control field, with no subfields or indicators and > MARC::Record is > treating it as a variable field (it's making the assumption that > unless a > tag is a control tag, ie < 010, a field should have indicators and > subfields). > > You can avoid the issue of alpha tags by setting an option in the > program > that exports MARC records from ALEPH (p_print_03), telling it to > exclude > alpha tags. Thank you for all the replies, and I consider this issue resolved, sort of. I appreciate that MARC is really a data structure. Leader. Directory. Data. Thus using alpha characters for field names is legitimate. This demonstrates the flexibility of MARC as a data structure. Considering the environment when it was designed, it is a marvelous beast. Sequential in nature to accommodating tape. Complete with redundant error-checking devices with the leader, the directory, and end-of- field, -subfield, and -record characters. Exploits the existing character set. It is nice that fields do not have to be in any particular order. It is nice that specific characters as specific position have specific meanings. For the time, MARC exploited the existing environment to the fullest. "Applause!" A computer science historian, if there ever will be such a thing, would have a field day with MARC. But now-a-days, these things are just weird. A novelty. I'm getting tired of it. Worse, many of us in Library Land confuse MARC as a data structure with bibliographic description. We mix presentation and content and think we are doing MARC. Moreover, I don't appreciate ILS vendors who "extend and enhance" the "standard" making it difficult to use "standard" tools against their data. This just makes my work unnecessarily difficult. Why do we tolerate such things? I won't even get into the fact that MARC was designed to enable the printing of catalog cards and the profession has gone on to use it (poorly) in so many other ways. If we in Library Land really want to live and work in an Internet environment, then we have some serious evolution to go through! The way we encode and make available our data is just one example. I feel like a dinosaur. BTW, position #1 of my leader contains a value of 2. Indicators are suppose to be two characters long. Yes, MARC::Batch (MARC::Field, probably) is treating FMT as a value greater than 010 and therefore expects indicators. Now I know why I am getting these errors. We have changed our Perl program to use the MARC::Batch strict_off method, and the problem went away -- got covered up. Finally, as this issue presented itself yesterday I said to my colleagues here in the office, "Let's consult the Oracle -- code4lib." It got a big chuckle, but it really is true. The Code4Lib Community really works, and works well. Prompt. Accurate. Diverse. code4lib++ Thank you. Whew! -- Eric Lease Morgan University of Notre Dam