[DCRM-L] For RBMS/BSC review: draft letter to OCLC

Wed Mar 19 18:17:25 MDT 2014

Nina,

For point 1, the attached letter to OCLC may assist with background. Also,
please see the BSC minutes of 2011 Midwinter (at which Annie Copeland
volunteered to draft the attached letter) and 2011 Annual (which report
that the letter was sent to OCLC).

My understanding was that all dcrm(x) codes *and *the predecessor codes
bdrb and dcrb were being protected But, it would be a good idea to get that
confirmed, and also to confirm whether OCLC needs to be contacted whenever
a new dcrm code is added or whether they are being automatically protected.

Stylistically, in your 4th sentence sentence, I would use the actual 040 $e
code values, e.g. dcrmb instead of DCRM(B). And, you've got DCRM(M) twice;
the second instance should be DCRM(MSS) [or dcrmmss, if you go that route].

Thanks for drafting this letter!

Randy

On Wed, Mar 19, 2014 at 5:03 PM, Robert Maxwell <robert_maxwell at byu.edu>wrote:

> I am quite surprised, in fact astounded, to hear that subfields $s and $f
> may be being removed from 240 fields. Do you have some examples where OCLC
> has done this? Since these subfields are in the authorized access points
> recorded in 1XX/240 and do exist in the authority records controlling those
> fields, programmatically removing them would be a major error that affects
> all kinds of cataloging in OCLC, not just rare materials records, if it in
> fact has been happening. I should think there would have been an immediate
> outcry beyond the dcrm list ...
>
> On point 4, their macro should not touch abbreviations in 245, 250, or 260
> whether they are in rare records or not. There is no way of knowing whether
> the abbreviation was on the original resource or not, and this applies to
> both rare and non-rare materials. OCLC should NOT be monkeying with
> abbreviations in these fields on any kind of record.
>
> Bob
>
> Robert L. Maxwell
> Ancient Languages and Special Collections Cataloger
> 6728 Harold B. Lee Library
> Brigham Young University
> Provo, UT 84602
> (801)422-5568
>
> "We should set an example for all the world, rather than confine ourselves
> to the course which has been heretofore pursued"--Eliza R. Snow, 1842.
>
>
> -----Original Message-----
> From: dcrm-l-bounces at lib.byu.edu [mailto:dcrm-l-bounces at lib.byu.edu] On
> Behalf Of Schneider, Nina
> Sent: Wednesday, March 19, 2014 5:48 PM
> To: DCRM Revision Group List (dcrm-l at lib.byu.edu)
> Subject: [DCRM-L] For RBMS/BSC review: draft letter to OCLC
> Importance: High
>
> Colleagues,
>
> Below is a draft of a letter that I'd like to send to Linda Gable of OCLC
> Quality Control on behalf of BSC. It's somewhat self-explanatory, but two
> different catalogers have brought these issues to my attention. If you are
> noticing any more problems with rare material bib records that haven't been
> mentioned here, please let me know. I will likely ask Linda or another OCLC
> rep to attend the BSC meeting at Annual if this needs to be discussed
> further.
>
> Any suggestions (or additions) would be appreciated before the end of the
> day on Friday so I can send it out on Monday.
>
> Thanks!
> Nina
>
>
>
>
> Dear Linda,
>
> It has come to the attention of the Bibliographic Standards Committee
> (BSC) of the Rare Books and Manuscripts Section (RBMS) of ACRL that OCLC
> has been revising bibliographic records that have been created or upgraded
> by the rare materials community. There are at least four separate issues:
> identification of rare material records, the removal of particular
> subfields in the 240, adding 33x fields to non-RDA records, and expansion
> of abbreviations. Until the time that BSC revises DCRM to align our catalog
> records with RDA, we urge OCLC to cease this practice as it is causing
> potential problems with the institutions affected.
>
> 1. Identification of rare material records.
> We understand that records coded 040$e dcrm(x) will not be touched. We
> also understand that it's been brought to OCLC's attention that 040 amremm
> should also be protected. Are legacy records of rare materials also
> protected? Those that are coded BDRB, DCRB, as well as DCRM(B), DCRM(S),
> DCRM(M), DCRM(G), and eventually DCRM(M) and DCRM(C) should also be
> protected. If they aren't, could you please update the "protected" list?
>
> 2. Removal of particular subfields in the 240.
> A cataloger at an academic library mentioned that subfield f and subfield
> s in the 240 are being removed by OCLC. This library is the inputting
> agency. Although the items are rare, it is this institution's policy to
> omit adding dcrmb in the 040 since the materials are late 19th- or early
> 20th-century. Why would these subfields be removed in the first place? If
> the cataloging agency is adding subfields to the uniform title and they are
> being subsequently deleted, is the only solution for protecting them to
> code these records "dcrmb"?
>
> 3. Adding 33x fields to non-RDA records.
>  The 338 terms (RDA carrier type) is currently unresolved. As you
> mentioned in your letter to Kate Moriarity (Wed, Mar 19, 2014 at 1:13 PM),
> " The question as to whether something described as "1 p." or "1 leaf",
> under a cover or not, versus "1 sheet" or "1 broadside" resulting in 338
> coded as "volume" or "sheet" is seemingly unresolved. We will make
> adjustments when guidelines make it clear what needs to happen." There is a
> concern about adding 33x fields to rare materials records before DCRM is
> revised for RDA. Is there a reason this cannot wait?
>
> 4. Expansion of abbreviations.
> In the same email response you wrote to Kate Moriarty on March 19th, "
> While we do rely on macros to do limited editing of the bib records to add
> elements that will ensure consistent indexing and retrieval (33X), I have
> verified that our macros do NOT touch abbreviations in the 245, 250, or the
> 260 field when the 040 $e is coded "dcrmb". At present we are not
> acknowledging the presence of "amremm" in the 040 $e, but we are fixing
> that oversight immediately, and those records will also be protected from
> changes to abbreviations in those fields."
> Our concern is that there are many instances where an abbreviation might
> be found in a field that is not 245, 250 or 260. DCRM(B), for example,
> instructs us to "Transcribe other title information not appearing on the
> title pages in a note, if considered important" (Rule 1D1). We are also
> instructed, in 7A4.2 to transcribe information from the publication or from
> other sources in quotation marks [in a note]. We can also transcribe
> contents from the title page in a note field. In fact, there are many
> instances of transcription in the 5xx fields that may include transcribed
> abbreviations. By limiting the abbreviation expansion to just the 2xx
> fields, it's quite possible that OCLC is creating difficulties for both
> librarians and patrons to identify items and actually changing the
> bibliographic record in significant ways.
>
>  We hope that OCLC understands these concerns and will cooperate with the
> rare book and manuscript community to resolve these problems. If you or
> your colleagues are able to make any suggestions on how we can protect our
> records from macros and automated revisions, we will appreciate it.
>
> Please don't hesitate to contact me with any questions or if you need
> clarification.
>
> Nina
>
>
> +---------------
> Nina M. Schneider
> Chair, RBMS Bibliographic Standards Committee
>
> Head Cataloger
> William Andrews Clark Memorial Library
> 2520 Cimarron Street
> Los Angeles, CA  90018
> (323) 731-8529
>
> nschneider at humnet.ucla.edu
> http://www.humnet.ucla.edu/humnet/clarklib/
>
>

-- 
Randal S. Brandt
The Bancroft Library | University of California, Berkeley
510.643.2275 | rbrandt at library.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20140319/2f0c64a7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oclcmergerequest2.doc
Type: application/msword
Size: 26112 bytes
Desc: not available
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20140319/2f0c64a7/attachment-0001.doc>