Re: [CODE4LIB] alpha characters used for field names
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. Tim Prettyman LIT/University of Michigan Library On 6/25/08 4:55 PM, Eric Lease Morgan [EMAIL PROTECTED] wrote: On Jun 25, 2008, at 4:37 PM, Steve Oberg wrote: Ok. What's allowable/possible vs. what is actually defined as part of variable MARC data fields in say MARC21. I'm amused by the hairsplitting. The bottom line is these particular fields are ALEPH specific and are not part of MARC21. I agree with others that accounting for these in whatever parsing program you use should not be a big deal. 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?
Re: [CODE4LIB] alpha characters used for field names
Harvey Hahn wrote: Unfortunately, the most limiting aspect of the 24-character leader is that fact that only 5 digits (the first 5 characters of the leader) were specified as the maximum length of a MARC record. Manipulating the various possible values of specific positions in the leader could lead to record/field/subfield sizes far larger than this, but the 5-digit (99,999 maximum) limitation is really *quite* limiting these days. The truly evil solution to the record length issue: If byte 0 is in the range '0'-'9', proceed as usual. If byte 0 is 'A'-'F', treat bytes 0-4 as a hexadecimal number, subtract 0x87960, and convert to decimal. That way, A becomes 10, and F becomes 493215. You've just quadrupled your maximum record length while retaining some semblance of backward compatibility. (NOTE: Like most of my evil format-hijacking suggestions involving a meat grinder and a shoehorn, I don't actually recommend putting this into practice. The pain and anguish would far outweigh the temporary benefit.) Michael -- Michael B. Klein Digital Initiatives Technology Librarian Boston Public Library (617) 859-2391 [EMAIL PROTECTED]
[CODE4LIB] alpha characters used for field names
Are alpha characters used for field names valid in MARC records? When we do dumps of MARC records our ILS often dumps them with FMT and CAT field names. So not only do I have glorious 246 fields and 100 fields but I also have CAT fields and FMT fields. Are these features of my ILS -- extensions of the standard -- or really a part of MARC? Moreover, does something like Marc4J or MARC::Batch and friends deal with these alpha field names correctly? -- Eric Lease Morgan
Re: [CODE4LIB] alpha characters used for field names
Eric, This is definitely not a feature of MARC but rather a feature of your local ILS (Aleph 500). Those are local fields for which you'd need to make a translation to a standard MARC field if you wanted to move that information to another system that is based on MARC. Steve On Wed, Jun 25, 2008 at 2:20 PM, Eric Lease Morgan [EMAIL PROTECTED] wrote: Are alpha characters used for field names valid in MARC records? When we do dumps of MARC records our ILS often dumps them with FMT and CAT field names. So not only do I have glorious 246 fields and 100 fields but I also have CAT fields and FMT fields. Are these features of my ILS -- extensions of the standard -- or really a part of MARC? Moreover, does something like Marc4J or MARC::Batch and friends deal with these alpha field names correctly? -- Eric Lease Morgan
Re: [CODE4LIB] alpha characters used for field names
On Wed, Jun 25, 2008 at 2:20 PM, Eric Lease Morgan [EMAIL PROTECTED] wrote: Moreover, does something like Marc4J or MARC::Batch and friends deal with these alpha field names correctly? I believe the Perl modules MARC::Batch/MARC::Record accept records with alphabetic characters as tags. Searching alpha tags (without quotes) at The Mail Archive for Perl4Lib [1] retrieves 6 messages in what appear to be two threads. [1] http://www.mail-archive.com/[EMAIL PROTECTED]q=alpha+tags I hope this helps, Bryan Baldus [EMAIL PROTECTED] [EMAIL PROTECTED] http://home.inwave.com/eija
Re: [CODE4LIB] alpha characters used for field names
Why don't systems use the 900 fields for local stuff like this? That's what they're there for, right? --Casey On Wed, Jun 25, 2008 at 12:23 PM, Steve Oberg [EMAIL PROTECTED] wrote: Eric, This is definitely not a feature of MARC but rather a feature of your local ILS (Aleph 500). Those are local fields for which you'd need to make a translation to a standard MARC field if you wanted to move that information to another system that is based on MARC. Steve On Wed, Jun 25, 2008 at 2:20 PM, Eric Lease Morgan [EMAIL PROTECTED] wrote: Are alpha characters used for field names valid in MARC records? When we do dumps of MARC records our ILS often dumps them with FMT and CAT field names. So not only do I have glorious 246 fields and 100 fields but I also have CAT fields and FMT fields. Are these features of my ILS -- extensions of the standard -- or really a part of MARC? Moreover, does something like Marc4J or MARC::Batch and friends deal with these alpha field names correctly? -- Eric Lease Morgan
Re: [CODE4LIB] alpha characters used for field names
Ok. What's allowable/possible vs. what is actually defined as part of variable MARC data fields in say MARC21. I'm amused by the hairsplitting. The bottom line is these particular fields are ALEPH specific and are not part of MARC21. I agree with others that accounting for these in whatever parsing program you use should not be a big deal. Steve On 6/25/08, Jonathan Rochkind [EMAIL PROTECTED] wrote: I believe that alpha characters for field names ARE legal according to (most of the various) MARC standard(s). But they are not generally used in library MARC data. Jonathan Eric Lease Morgan wrote: Are alpha characters used for field names valid in MARC records? When we do dumps of MARC records our ILS often dumps them with FMT and CAT field names. So not only do I have glorious 246 fields and 100 fields but I also have CAT fields and FMT fields. Are these features of my ILS -- extensions of the standard -- or really a part of MARC? Moreover, does something like Marc4J or MARC::Batch and friends deal with these alpha field names correctly? --Eric Lease Morgan -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu
Re: [CODE4LIB] alpha characters used for field names
On Jun 25, 2008, at 4:37 PM, Steve Oberg wrote: Ok. What's allowable/possible vs. what is actually defined as part of variable MARC data fields in say MARC21. I'm amused by the hairsplitting. The bottom line is these particular fields are ALEPH specific and are not part of MARC21. I agree with others that accounting for these in whatever parsing program you use should not be a big deal. 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? -- Eric
Re: [CODE4LIB] alpha characters used for field names
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. Unfortunately, the most limiting aspect of the 24-character leader is that fact that only 5 digits (the first 5 characters of the leader) were specified as the maximum length of a MARC record. Manipulating the various possible values of specific positions in the leader could lead to record/field/subfield sizes far larger than this, but the 5-digit (99,999 maximum) limitation is really *quite* limiting these days. The 5-digit base address in positions 12-16 might pose a similar problem. But people were thinking in catalog card terms back at the beginning of MARC. It's sort of like, are we putting unconscious limitations on anything today in our specifications that future generations might wish *we* had done differently? Harvey -- === Harvey E. Hahn, Manager, Technical Services Department Arlington Heights (Illinois) Memorial Library 847/506-2644 - FX: 847/506-2650 - Email: hhahn(at)ahml(dot)info OML Scripts web pages: http://www.ahml.info/oml/ Personal web pages: http://users.anet.com/~packrat