What is MARC format? (Was: My ALA talk)

Posting to Autocat

On 08/07/2011 18:04, J. McRee Elrod wrote:

> Eric Hellman said:

I don’t remember “dismissing the value of almost everything we do as librarians.” I’ll admit to complaining (sarcastically) about the technical deficiencies and practical drawbacks of MARC ..

We find the “technical deficiencies” to be in present ILSs, not in MARC. Today’s ILSs have hardly scratch the surface of what could be done with MARC, or cross walks from MARC.

It is easier to cross walk from MARC to other schema, than the reverse. For example, a cross walk MARC record from IMBD or ONIX takes quite a bit of editing. But with the addition of images, either can be produced from MARC. URLs for full electronic text are a commonplace; for one of our clients, we are now including URLs for cover images. MARC is a far more versatile tool than many suppose.

I think it’s important to discuss precisely what constitutes the MARC format so that everyone is talking about the same thing. At its most basic level, there is the ISO2709 format which is used only to transfer complete catalog records (i.e. cards) among library catalogs, and this is definitely obsolete today. Because of this 1960s foundation, everything from then on becomes limited based on that format: limited record length, a limited number of fields and subfields, and then concerning the information in the fixed fields, this is very difficult to extract without the special library software. Also, a certain structure is embedded ISO2709. As I have mentioned, allowing for the possibility of multiple main entries, to allow for primary/secondary authorship, would be very difficult to institute in ISO2709, if it is even possible, but very easy in XML. I am sure there are other problems as well.

Another level of the MARC format is what specialists (catalogers) work with: the field numbers and subfield codes, such as 245$a, mean something highly specific to us, but are meaningless to anyone else. Still, just converting 245$a to a so-called “human readable” version is very difficult. Having it display as “Title proper” still means nothing to people since this is specialist jargon. I keep going back and forth on this because “245$a” is language independent while <titleProper> means something only to specialist English speakers.

Although I still believe that
on the order of MARCXML would be better in the long run than English words that don’t mean anything to a non-cataloger anyway, just use 245$a and make different stylesheets, but… I was argued down and I had to admit that developers just won’t do that. OK–it’s just some stupid computer codes: go with English-language coding.

So, if we had the same “semantics” as we do today with MARC, but the new format actually said, instead of
it could be:
the two would function identically, and catalogers could get it to display the numbers and subfields anyway. Like I said, it’s just a bunch of stupid computer codes and any one code can work as well as any other.

So, there are (at least) three distinct levels to MARC format: the ISO2709 format, the field numbers with subfield codes, and the higher-level semantics. It is the higher-level semantics that are important to retain while the remainder: the field/subfield numbers and codes, plus the ISO2709 format can be safely tossedoverboard, i.e. once the correct systems are in place.