MARC::Field::new_from_usmarc problems
Dear all,
I was wondering if there is anyone from the MARC::Record team on this
list who possibly could give some insight in the following matter.
We are using MARC::Record to manipulate MARC records in Emilda [1] and
we have been running into some unexpected problems. The actual
manipulation code has not been altered lately, but people were reporting
that MARC manipulation was behaving weird when testing Emilda. As such
we had to look into the matter, and found out that there indeed was
something weird going on, at least with some certain setups.
I managed to reproduce the error (I'm not quite sure if it is because of
MARC::Record, but since it is MARC::Record that reports the error, I'm
assuming it is) and added some debugging information to the code to see
what is happening.
Here is a snipplet from the code, that displays the debugging information:
<<<<
print "RAW: ".$self->{'MARC_blob'}."\n";
$record = MARC::Record::new_from_usmarc($self->{'MARC_blob'}) or die $!;
print "RES: ".$record->as_formatted()."\n";
print "WARN: ".join("\n", $record->warnings())."\n";
>>>>
and what this outputs is:
<<<<
RAW: 02599nam 2200025 a
45040010011000300111005001700021008003900038020002300077035001500100035001900115035003300134047001670420012001740840021001860840018002071270022524500380025226000530029034100343599001000384653001600394653003200410653002000442653001600462653001900478653002000497841004800517841004800565841004800613841004800661841004800709841004700757841004900804841004700853841004900900841004700949841004700996841004801043841004901091841004701140841004901187841004901236841004801285841004701333841004901380852001101429852002501440852001701465852001301482852001301495852001701508852001101525852002901536852002201565852001101587852001701598852002801615852002601643852002401669852002501693852002101718852003801739852001101777852001801788976002301806 000286 ESBO_STAD 20031030130634.0 990309s1999
sw j 001 0 swe a9129646103 c183:00 99129646103
5Bo a(Bo)368396 5Lahv a(MMLahv)1999025970
aNB 9NB 9SEE 5SEE aUgg 2kssb/6 aUgg,u 2kssb/6 1
aJansson, Hasse, d1949- 00 aTitta på fåglar! / cHasse Jansson
aStockholm : bRabén & Sjögren, c1999 ; e(Danmark) a61, [2] s.
: bfärgill. ; c18 x 22 cm aLi: S 5Sbi aFåglar
5Lahv aFåglar aArtbestämning 5La aFaktaböcker 5Jon aFåglar
5La aBarnböcker 5Jon aBarnböcker 5Gp axa b0201080u0
4000uu |00 e1 5Li axa b0201080u0 4000uu
|00 e1 5La axa b0201080u0 4000uu |00 e1
5Um axa b0201080u0 4000uu |00 e1 5Kd axa b0201080u0
4000uu |00 e1
5Mo au b030828|||001||00 e1 5Jon axa b0201080u0
4000uu |00 e1 5L axa b0201080u0 4000uu
|00 e1 5Hsd axa b0201080u0 4000uu |00 e1
5O axa b0201080u0 4000uu |00 e1 5Q axa b0201080u0
4000uu |00 e1 5Sk axa b0201080u0 4000uu
|00 e1 5Sbi axa b0201080u0 4000uu |00 e1
5Bo ax b0201070u0 4000uu021001 e1 5SEE axa b0201080u0
4000uu |00 e1 5Hls axa b0201080u0 4000uu
|00 e1 5NB axa b0201080u0 4000uu |00 e1
5S axa b0201080u0 4000uu |00 e1
5Lahv au b030616|||001||00 e1 5Mo bMo
5Lahv bLahv hUgg xSus 5La bLa huUgg 5SEE bSEE
5Hsd bHsd 5Gp bGp huUgg 5Sk bSk
5Hls bHls hUgg,u jJansson 5Li bLi cCNB hug,u 5Um bUm
5Kd bKd hUg,u 5Jon bJon hUg BARN jJANS
5L bL c0200 h299/ j102 5O bO huUgg jJansson
5Q bQ clära hUg,u Jan 5S bS hSv99 j2878
5NB bNB cNB99:12 hgåva jKU, 990602 5Bo bBo 5Sbi bSbi jRef
2 aUgg,u bFåglar Aves
RES: LDR 02599nam 2200025 a 4504
WARN: No directory found in record 1
>>>>
"RAW" is the original MARC record to be manipulated and thus imported
using new_from_usmarc(), but this seems to fail for some reason that is
not apparent, at least to me.
Any help on the matter is deeply appreciated as I really cannot make
anything of this, as it was working on my setup, but not on various
other peoples setups.
Regards,
--
[1] http://emilda.org
--
Christoffer Landtman
Oy Realnode Ab
Partner, Sales
+358 (0)41 510 1073
[EMAIL PROTECTED]
www.realnode.fi
Re: Manuall created records
Ed Summers wrote: On Wed, Oct 15, 2003 at 02:25:55PM +0100, Ashley Sanders wrote: The record isn't strictly correct as the Indicator count and Subfield code length are both blank (character positions 10 and 11.) MARC21 says these should always be set to 2. Also the Lenght of length-of-field, length of starting-character-position and length of implementation-defined (positions 20, 21, 22) should also be set to 4, 5, and 0 respectively. Position 22 should also be 0. Thanks for the details Ashley. When building a MARC record, and the leader is not specified with the MARC::Record::leader() method, then a minimal leader is built, with an autopopulated record length (positions 0-4), and base address of data (positions 12-16)...but that's it. I've entered a bug [1] in to rt.cpan.org indicating that the autopopulation should also add other MARC21 defaults as specified here [2] Chritoppher, for the time being (ie. until he method is fixed) you can always specify the leader yourself and include the positions that Ashely mentions. ## build leader piecemeal my $ldr = ' ' x 24; substr( $ldr, 10 ) = 2; substr( $ldr, 11 ) = 2; substr( $ldr, 20 ) = 4; substr( $ldr, 21 ) = 5; substr( $ldr, 22 ) = 0; $r->leader( $ldr ); It would be interesting to know if this was what was throwing Zebra. Thanks very much for posting to the list, and let us know if there are any more developments. A new MARC::Record should be available soonish. //Ed [1] https://rt.cpan.org/Ticket/Display.html?id=4113 [2] http://www.loc.gov/marc/bibliographic/ecbdldrd.html Hello again. After addding the new "information" into the leader specified by Ashley and using the code snipplet from Ed (however adding the third argument into substr) i got a record that was accepted by Zebra. I will experiment more on the subject, and will most certainly appear here again if i run into trouble. The character at position 24 which according to Ashley should be a field terminator instead of blank, did apparently not affect Zebra. I do not know if this is good or bad (Zebra too sloppy or Ashley too strict...=) but for the time being, it seems to work. Btw: there seems to be some subfields that are valid but have not been entered into MARC::Lint since they according to http://www.loc.gov/marc/bibliographic/ecbdldrd.html are valid but Lint tells me they are wrong. Can it be that only the most common subfields have been entered into MARC::Lint? Well, anyways, i thank You all, and be sure to see me here again when i have run into trouble. -- Christoffer Landtman Oy Realnode Ab Partner, Sales +358 (0)41 510 1073 [EMAIL PROTECTED] www.realnode.fi
Re: Manuall created records
Ashley Sanders wrote: Christoffer, i.e. Zebra treats the record as being empty. 00154 00085 0010011000300090001100500170002011600037245001500053 01 REALNODE 20031015153536.0 1 aTest Author 00 aTest Title The record isn't strictly correct as the Indicator count and Subfield code length are both blank (character positions 10 and 11.) MARC21 says these should always be set to 2. Also the Lenght of length-of-field, length of starting-character-position and length of implementation-defined (positions 20, 21, 22) should also be set to 4, 5, and 0 respectively. Position 22 should also be 0. Also the character at position 25 should be the field terminator character, not a blank. So, I think your record should look like: 00154 2200085 450 0010011000300090001100500170002011600037245001500053 01 REALNODE 20031015153536.0 1 aTest Author 00 aTest Title If an application such as zebra is doing things correctly, then it has every right to think the record is bad if it sees these errors. Of course, it may be something else completely. Regards, Ashley. Thanks for the enlightment. So what You quietly imply is that there seems to be some anomalies in the way MARC::Record creates MARC records, since the output of my MARC record is directly from this script? Anyone part of the MARC::Record project here to comment on this matter? I believe this was the most complete ansver i have gotten in a long time about this matter, so i thank You and hope that someone from MARC::Record could comment on the matter and tell me if i'm doing something wrong, or if MARC::Record does not have the capability to create records in accordance with what You just told me. Tanks again! -- Christoffer Landtman Oy Realnode Ab Partner, Sales +358 (0)41 510 1073 [EMAIL PROTECTED] www.realnode.fi
Manuall created records
Dear all,
I want to create records manually, and i am using MARC::Record to do
this. Records come out but they are not accepted by e.g. Zebra due to
some strange reason. I have been talking with some guys over on the
Zebra list, and they seem to be of the oppinion that the fault lies in
the MARC record.
Here is shortly my test setup:
I have the following Perl script to generate the test MARC record:
-
#!/usr/bin/perl -l
use MARC::Record;
use MARC::Lint;
$marc = new MARC::Record;
$lint = new MARC::Lint;
$field_001 = MARC::Field->new('001', '01');
$field_003 = MARC::Field->new('003', 'REALNODE');
$field_005 = MARC::Field->new('005', '20031015153536.0');
$field_100 = MARC::Field->new('100','1','','a' => 'Test Author');
$field_245 = MARC::Field->new('245','0','0','a' => 'Test Title');
$marc->append_fields(($field_001, $field_003, $field_005, $field_100,
$field_245));
open OUT, ">01" or die($!);
print OUT $marc->as_usmarc();
close OUT;
$lint->check_record($marc);
print join( "\n", $lint->warnings ), "\n";
I have this script saved as test.pl, and when running it, i get no
errors, even though i have the Lint-function in MARC::Record in use.
[EMAIL PROTECTED] perl]$ ./test.pl
[EMAIL PROTECTED] perl]$
Here is the formatted output of the MARC record using the marcdump
script supplied with MARC::Record:
[EMAIL PROTECTED] zebra]$ marcdump temp_records/1
temp_records/1
LDR 00154 00085
001 01
003 REALNODE
005 20031015153536.0
100 1 _aTest Author
245 00 _aTest Title
Recs Errs Filename
- -
1 0 temp_records/1
[EMAIL PROTECTED] zebra]$
However, when updating Zebra to index the newly created record, it does
not accept this and returns the following 'error':
15:44:11-15/10: zebraidx(3122) [log] Zebra version 1.3.10 $Date:
2003/04/01 07:48:21 $
15:44:11-15/10: zebraidx(3122) [log] zebra_start zebra.cfg
15:44:11-15/10: zebraidx(3122) [log] zebra_begin_trans
15:44:11-15/10: zebraidx(3122) [log] updating temp_records
15:44:11-15/10: zebraidx(3122) [log] dir temp_records/
15:44:11-15/10: zebraidx(3122) [warn] empty grs.marc.usmarc
temp_records/1 0
15:44:11-15/10: zebraidx(3122) [log] zebra_end_trans
15:44:11-15/10: zebraidx(3122) [log] sorting section 1
15:44:11-15/10: zebraidx(3122) [log] writing section 1
15:44:11-15/10: zebraidx(3122) [log] finished section 1
15:44:11-15/10: zebraidx(3122) [log] Iterations . . . 45
15:44:11-15/10: zebraidx(3122) [log] Distinct words . 19
15:44:11-15/10: zebraidx(3122) [log] Updates. . . . . 0
15:44:11-15/10: zebraidx(3122) [log] Deletions. . . . 0
15:44:11-15/10: zebraidx(3122) [log] Insertions . . . 19
15:44:11-15/10: zebraidx(3122) [log] Records: 0 i/u/d 0/0/0
15:44:11-15/10: zebraidx(3122) [log] user/system: 1/1
15:44:11-15/10: zebraidx(3122) [log] zebra_stop
15:44:11-15/10: zebraidx(3122) [log] zebraidx times: 0.09 0.01 0.01
[EMAIL PROTECTED] zebra]$
i.e. Zebra treats the record as being empty.
I attach the raw MARC file (1) if it helps anyone. All hints are
most welcome, since i am getting fairly lost with all different
oppinions, since i am no MARC expert.
Thanks in advance!
--
Christoffer Landtman
Oy Realnode Ab
Partner, Sales
+358 (0)41 510 1073
[EMAIL PROTECTED]
www.realnode.fi
00154 00085
0010011000300090001100500170002011600037245001500053 01 REALNODE 20031015153536.0 1
aTest Author 00 aTest Title
