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
> 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
> 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
>> 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
> You can avoid the issue of alpha tags by setting an option in the
> that exports MARC records from ALEPH (p_print_03), telling it to
> alpha tags.
Thank you for all the replies, and I consider this issue resolved,
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
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++
Eric Lease Morgan
University of Notre Dam