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!