Subject: [CODE4LIB] marc21 and usmarc

From: Eric Lease Morgan <[email-masked]>
Date: Thu, 22 Jan 2009 11:28:26 -0500

Does anybody here know the difference between MARC21 and USMARC?

I am munging sets of MARC bibliographic data from a III catalog with
holdings data from the same. I am using MARC::Batch to read my bib' data
(with both strict and warnings turned off), insert 853 and 863 fields, and
writing the data using the as_usmarc method. Therefore, I think I am
creating USMARC files. I can then use marcdump to... dump the records. It
returns 0 errors.

We are then attempting to feed these files to Ex Libris's Primo but it
chokes on my data with the following error complete with spelling mistakes:

  2009-01-21 16:47:33,369 ERROR [t-SplitRecords] [c-RecordSplitter]
  - An exception occured while splitting record. error message is
  Content is not allowed in prolog.

Apparently we need to tell Primo that my data is one of the following
formats:

  MARC21
  MAB
  DANMARC2
  UNIMARC
  MARC Exchange

In what way is USMARC different from any of the formats above, and is it
possible to use the MARC::Record family of modules to write flavors of MARC
other than USMARC.

(Alternatively, maybe instead I need to turn strict and warning on and
filter out any bad records. Hmmm... )

-- 
Eric Lease Morgan
University of Notre Dame

---

From: Bryan Baldus <[email-masked]>
Date: Thu, 22 Jan 2009 10:45:11 -0600

>Does anybody here know the difference between MARC21 and USMARC?

For your purposes, MARC21 and USMARC are the same. USMARC became MARC 21 through evolution, but structurally, they are the same. The only differences are in field/subfield definitions. I believe this also the case for UNIMARC (though in that case, the field definitions are much different)--I think Koha uses MARC::File::USMARC for manipulating both MARC 21 and UNIMARC flavors.

>(Alternatively, maybe instead I need to turn strict and warning on and filter out any bad records. Hmmm... )

That would be recommended. I've have a .pl, rawanddecodedscan [1], that reads a file of raw MARC and reports structurally problematic records (as .txt and .mrc files). MARC::Lint (from CPAN) (and Lintadditions (from my site, though my ISP has changed the way it deals with directories)) might be useful for finding problems in structurally-sound MARC files.

[1] <http://home.inwave.com/eija/fullrecscripts/rawanddecodedscan.txt>, uses MARC::BBMARC, which is part of MARC::Errorchecks (from CPAN).

I hope this helps,

Bryan Baldus
[email-masked]
[email-masked]
http://home.inwave.com/eija

---

From: "Ya'aqov Ziso" <[email-masked]>
Date: Thu, 22 Jan 2009 12:16:09 -0500

see >>YZ below:

>> for all intensive purposes they are synonimous (USMARC at its 21 iteration is
MARC21)

YZ >> it¹s this!

MAB
>> German MARC

DANMARC2
>> Danish MARC

UNIMARC
YZ >> some European counries¹ MARC

MARC Exchange
>> shouldn¹t be different from MARC21; use MARC21 to be on the safe side
>

---

From: Eric Lease Morgan <[email-masked]>
Date: Thu, 22 Jan 2009 12:26:43 -0500

On 1/22/09 11:45 AM, "Bryan Baldus" <[email-masked]> wrote:

> That would be recommended. I've have a .pl, rawanddecodedscan [1], that reads
> a file of raw MARC and reports structurally problematic records (as .txt and
> .mrc files). MARC::Lint (from CPAN) (and Lintadditions (from my site, though
> my ISP has changed the way it deals with directories)) might be useful for
> finding problems in structurally-sound MARC files.
> 
> [1] <http://home.inwave.com/eija/fullrecscripts/rawanddecodedscan.txt>, uses
> MARC::BBMARC, which is part of MARC::Errorchecks (from CPAN).

Argg! After tweaking the code found in the synopsis of MARC::Lint, I
discovered that my input has a billion errors!! 'More later, after I figure
out whether nor not this is part of the issue...

  marc::lint++
  bryan.baldus++

-- 
Eric Lease Morgan

---

From: Till Kinstler <[email-masked]>
Date: Fri, 23 Jan 2009 09:15:04 +0100

>>> German MARC

Just to note that:
MAB is (unfortunately) not a "German MARC", it is structurally and 
semantically totally different from any MARC dialect. So it is really 
hard to work with MAB data, because all the nice open source tools for 
processing bibliographic records (MARC::Record, marc4j, software based 
on that like solrmarc ...) are hard to use in applications for German 
libraries. There are no nice OS programming libraries for handling MAB...
There are ongoing efforts to promote MARC 21 in Germany. There is even a 
resolution by the German library standardization board to switch to MARC 
21 as official interlibrary exchange format dating back to 2004. But in 
practice, MARC 21 doesn't play any role yet in Germany... That makes it 
really hard to promote some Open Source solutions that focus primarily 
on MARC data (not so much for technical reasons).

-- 
Till Kinstler
Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG)
Platz der Göttinger Sieben 1, D 37073 Göttingen
[email-masked], +49 (0) 551 39-13431, http://www.gbv.de