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