I am reminded of an amusing collective cringe at the libraries and linked data  workshop at the British Library, when one of the software engineers expressed puzzlement over the inclusion of punctuation in the data fields.

(MARC21 followed USMARC rather than the more semantic UKMARC approach. Wounds were still a bit raw. )

José-Marie Griffiths told me that  USMARC was originally seen as sort of text markup language, which explains some of the historical divergence.

Also, too many programmers have to understand raw "marc", because too much code produces broken records, and there are too many opportunities for catalogers to introduce secret characters unintentionally (e.g. cut and paste that copies a field terminator into the middle of a field).  Still not as common as punctuation errors though.

Simon

On Feb 5, 2013 7:37 AM, "Heuvelmann, Reinhold" <[log in to unmask]> wrote:
Well, John had me blushing here -- I very much appreciate the level of agreement  :-)

My mantra regarding the punctuation issue, the mark up and content designation (which for me is intertwined with granularity in ISBD and MARC) is:

You may be interested in the Final Report of the "PCC ISBD and MARC Task Group" which was chaired by Robert Bremer (OCLC), announced at [1] and available at [2].

It contains a list of MARC field numbers where terminal periods may be omitted without any loss of specificity [Appendix A]; detailed discussions of fields where there is too little granularity [Appendix B], summarized in [Appendix C]; and a list of fields which require no punctuation and coding changes [Appendix D].  If any, a close look at the whole record examples in [Appendix E] may give a picture of the intention.

[1] [log in to unmask]" target="_blank">http:[log in to unmask]
[2] http://www.loc.gov/aba/pcc/sca/documents/isbdmarc.docx [Word document, 78 pages, 132 kb in size)

Best wishes

Reinhold

--

Reinhold Heuvelmann
German National Library
IT / Office for Data Formats
Adickesallee 1
D-60322 Frankfurt am Main
Germany
Telephone: +49-69-1525-1709
Telefax: +49-69-1525-1799
mailto:[log in to unmask]
http://www.dnb.de

*** Reading. Listening. Understanding. German National Library ***


-----Ursprüngliche Nachricht-----
Von: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] Im Auftrag von Myers, John F.
Gesendet: Donnerstag, 31. Januar 2013 17:34
An: [log in to unmask]
Betreff: Re: [BIBFRAME] Punctuation

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.