Print

Print


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]
> 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.
>