I was strongly reminded during the BibFrame Forum at ALA MidWinter, in a presentation on the Deutsche Nationalbibliothek's experience with BibFrame, that MARC was designed as a COMMUNICATION format. In the U.S., we have since leveraged it as a storage format and cataloging interface, to our current dismay. Not so for our German colleagues, who use MARC strictly as it was intended, for communication, and have separately developed systems for the other functions. As we continue to run afoul of assumptions about how BibFrame does or does not meet the functionality of MARC, I can't help but feel that our German peers have taken the more productive road, one that has preserved the intellectual integrity of MARC.
Very, very few people understand a 'raw' MARC record, even experienced catalogers -- not the prettified displays we see in OCLC or our ILS, but the gnarly string of digits and characters. Catalogers and users should no more need to see or understand raw BibFrame data either.
For all that ISBD punctuation is the grand-daddy of data mark up, and elegant in its conciseness (and for all that it pains me to see a catalog record, MARC or otherwise, that lacks it), the point remains that it is mark up. We now have much more effective mechanisms to mark up and parse data -- we should use them. It is counter-productive to have mark up mean different things depending on where it occurs -- a colon in field 245 (aka ISBD Title and statement of responsibility area) means "other title information," where in field 260 (aka, ISBD publication statement area) means "publisher," etc. We can mark up these things explicitly using XML or other means. If we subsequently desire to display them with language appropriate labels, that can be done; if we want to compile the data into an ISBD display, that too can be done.
Whatever the eventual COMMUNICATION format is that emerges from the BibFrame development process, it should focus on accurately conveying both data and its nature. It should support the eventual presentation of data in mechanisms that similarly convey the data and its nature, but it does NOT need to provide that display in and of itself. Just as the letters I type here are translated first into ones and zeros and then back into the letter forms corresponding to what I typed, so too should the new communication format and its interfaces convert entry by a cataloger into something useable by the computer and then back into something comprehensible to another human being.
John F. Myers, Catalog Librarian
Schaffer Library, Union College
Schenectady NY 12308
[log in to unmask]
518-388-6623
-----Original Message-----
J. McRee Elrod wrote:
Quoting Nate Trail:
>If it's in a MARC record, there's no need to guess, because the
>subfields are already parsed parts. Title proper is 245$a, subtitle is 245$b, etc.
Mac replies:
Most patrons never see the MARC record. I'm talking about the OPAC display.
I know of no OPAC which displays the subfield codes. A few allow patrons to click "MARC", but I've never seen anyone but a cataloguer do that.
While if viewed, the MARC subfield codes parse parts, only a tiny minority of people would be able to read with understanding a Bibframe html marked up record. They are dependent on the display based on that record. That display needs punctuation. Punctuation is more likely to be consistent from system to system if in the record.
|