10 October 2007

on MARC

this one's from one of the blogs I read: Nicole points to a posting by Chris Schwartz on the future of MARC.

MARC is a sore point amongst cataloguers (or at least in the Anglo-American context): There are armed camps both for MARC and against it.

MARC itself is a data standard, or rather an implementation of a data standard (ISO 2709). It has been used for over 30 years in the library world, initially devised to print catalogue cards from bibliographic data, then used mostly to transmit bibliographic data between systems (for example, between different libraries, or between libraries and their users, through the Z39.50 retrieval protocol; if you've ever used EndNote or similar software to search library catalogues, you've more than likely retrieved MARC records).

I know of no library automation system that uses MARC to store data. MARC data may be imported into an ILS, but the system then parses out that data and stores it within its own database architecture (for example into records within a set of tables in a relational database system).

Now comes point number one. Repeat after me. Systems do not store data as MARC records. Got it? Good.

The problem the anti-MARC factions ignore, is that MARC is also used as an interface language (if you like) for cataloguers: Cataloguers like to think in terms of MARC tags and subtags and indicators. Instead of thinking of additional authors, we thin of "700" tags. Instead of thinking of titles we think of "245"s. Instead of thinking of subjects we think of "650"s. Or "630"s. Or "610"s. Or "600"s.

Of course, cataloguers don't really think in MARC: Cataloguers have become used to a parsed version of the MARC record, where the bibliographic data is neatly arranged in a page-like layout. This is not MARC. This is the bibliographic data, pulled from the database system, and arranged . For example, most cataloguers might look at something like this

000 00878cam a22002771a 450
001 10347858
906 __ |a 7 |b cbc |c oclcrpl |d u |e ncip |f 19 |g y-gencatlg
005 20060316181511.0
008 751210s1965 enk 000 1 eng
035 __ |9 (DLC) 66070332
010 __ |a 66070332
015 __ |a GB66-4853
035 __ |a (OCoLC)1888047
040 __ |a DLC |c FU |d MdU |d Uk |d DLC
041 1_ |a eng |h fre
042 __ |a premarc
050 00 |a PZ3.S2494 |b Nau5
100 1_ |a Sartre, Jean-Paul, |d 1905-1980.
240 10 |a Nausée. |l English
245 10 |a Nausea / |c Jean-Paul Sarte ; translated from the French by Robert Baldick.
260 __ |a Harmondsworth, Middlesex, England : |b Penguin, |c 1965.
300 __ |a 252 p. ; |c 19 cm.
500 __ |a Translation of: La nausée.
700 1_ |a Baldick, Robert.
985 __ |e OCLC REPLACEMENT cdsdistr
991 __ |b c-GenColl |h PZ3.S2494 |i Nau5 |t Copy 1 |w OCLCREP


(taken from the Library of Congress catalogue) and say "That's a MARC record." In fact, the MARC record looks like this:

00876cam 22002771a 450000100090000090600450000900500170005400800410007103500210011201000170013301500140015003500190016404000260018304100130020904200120022205000200023410000350025424000220028924500780031126000570038930000210044650000320046770000210049998500300052099100480055010347858 a7bcbccoclcrplduencipf19gy-gencatlg20060316181511.0751210s1965 enk 000 1 eng  9(DLC) 66070332 a 66070332  aGB66-4853 a(OCoLC)1888047 aDLCcFUdMdUdUkdDLC1 aenghfre apremarc00aPZ3.S2494bNau51 aSartre, Jean-Paul,d1905-1980.10aNausâee.lEnglish10aNausea /cJean-Paul Sarte ; translated from the French by Robert Baldick. aHarmondsworth, Middlesex, England :bPenguin,c1965. a252 p. ;c19 cm. aTranslation of: La nausâee.1 aBaldick, Robert. eOCLC REPLACEMENT cdsdistr bc-GenCollhPZ3.S2494iNau5tCopy 1wOCLCREP

Not exactly human-readable, is it?

So here comes my point number two. Again, repeat after me. Cataloguers do not really use MARC. Got it? Well okay.

There are alternatives to MARC, some even built from MARC (MARC-XML come to mind). But what many cataloguers imagine when they look at MARC-XML (and the anti-Marc lobby haven't exactly disabused them of this), is that they'd have to work on records at the XML level. Why? We do not work directly on MARC now, why would we have to work directly with XML in the future? that's what interface designers do; they design applications that allow us to work on the records without ever seeing what they really look like!

2 comments:

Nicole said...

I agree 100%! And my argument is that our systems were built to read MARC - or at the very least the MARC fields we're used to entering as catalogers. Which means that MARC as a standard can't really go away overnight - it would require redeveloping all of our systems to understand new fields and values.

The cataloger's argument is that they'd have to learn where to put that title now that it's not 245 ... or maybe it's not - maybe it's just change - the big bad evil horrible idea of change.

That's just a mini-rant comment from me :)

carlos lopez librarian said...

Thanks Nicole.

Resistance to change is a powerful force, wherever we find it. Which is something I sometimes find strange, as change is the only constant we can really count on.

 
Add to Technorati Favorites View carlos lopez's profile on LinkedIn