[DCRM-L] "Private" fields in OCLC

Carol Fink cfink2 at michigan.gov
Tue Dec 11 13:53:46 MST 2007


Dorothy,
Bib formats and standards p. 5:91 says the 590 is set to not display
and both indicators are undefined. Our understanding is that undefined
indicators means OCLC has not assigned a code to input into either
field. I'm not sure you could even use a 1 in the first indicator field
and have it make a difference. 
 
I'll be interested to hear if OCLC tells you differently. 
Carol Fink
Library of Michigan
 
 

>>> "Auyong, Dorothy" <dauyong at huntington.org> 12/11/2007 3:14 PM >>>

But does this mean that those of us who transitioned from RLIN should
NOW be coding our 590s to display?  This was never brought to our
attention during training and we continued to use MARC practice.  Our
Manuscript catalogers *cleaned up* their private 590s when the ARC
segment vanished and none of us have been using the 590 for private
information and would like them to display in our institution records.
If the default is to *mask* these, we might need to consult with OCLC
during the upload of our RLIN records (we opted to send them from our IL
instead of from RLIN) so that they*re globally set to display.  Our
database manager is going to LOVE this one.  He already thinks rare book
records are a PIA <smile>  Ok, not quite, but I do sometimes think he
thinks we*re crazy. <sigh> Dorothy AuyongPrincipal Rare Book
CatalogerHuntington Librarydauyong at huntington.org 
From: dcrm-l-bounces at lib.byu.edu [mailto:dcrm-l-bounces at lib.byu.edu] On
Behalf Of Margaret Nichols
Sent: Tuesday, December 11, 2007 11:02 AM
To: DCRM Revision Group List
Subject: Re: [DCRM-L] "Private" fields in OCLC
 I suspect that it's being proposed to make the 590 field private by
default because it contains some of the collection management
information that used to go in the "ARC segment" of manuscript and
archival collections in RLIN. All that collection management info was
private by virtue of being in the ARC segment, and so it remained until
the advent of RLIN21, when the ARC segment was discontinued and the data
got put into 541, 583, and 590 fields. So now there are scads of records
out there with lots of 541s, 583s, and 590s, with no indicators, whose
content was never intended to be seen by the public. Our newly minted
590s typically contain box locations (fortunately, outdated ones). If
any of these fields were to be defined as public by default, it would be
rather disastrous: purchase prices, donors' names and addresses,
deaccessioning plans, box locations, all would be visible to users all
over the world. No, thank you.

Best,

Margaret



At 10:55 AM 12/11/2007, you wrote:

I understand a group called *The RLG Union Catalog Advisory Committee*
has discussed the issue of private information in local records with
OCLC and has *ratified* the following decision. I may be totally out of
the loop, but I hadn*t heard a whisper about it and thought maybe you
all hadn*t either. I am certain it was not discussed on this rare
cataloging discussion list, at any rate, and it does affect us.
 
It appears that this Committee wanted to ensure that *all possible
private information was protected.* By *private* I assume things like
donors, prices paid, etc., is meant. Four fields were discussed:
 
541, 561, 583, and 590
 
The Committee decided that in OCLC, the first indicator in any of these
field must be coded *1*  for the field to display. In other words, if
the indicator is coded *blank* or *0* the field will not display. (In
the MARC format documentation for 541, 461, and 583, *0* means private,
*1* means not private, *blank* means no information provided. No such
coding is defined for 590.)
 
I am particularly concerned about this decision with respect to 590,
and also to some extent about 561. It appears that (nonstandard)
indicators 1 and 0 have been available for some time in OCLC for 590,
but to my knowledge they were never so defined in RLIN, and so no 590s
coming from RLIN libraries will be so coded. Therefore by fiat none of
the 590s currently in RLIN-originated records, and probably in most
OCLC-originated records (I*d be interested in hearing from OCLC
catalogers if they used these indicators), will display. Wasn*t that one
of the major points about RLG libraries wanting the institution records,
that the local information would display? This action will defeat that
purpose for the majority of records.
 
I am not in favor of *opt in* for 590, in other words, you have to
manually insert an indicator or it will not display. It seems to me that
if anyone has actually put private information in a 590 (something I
would never do in my own cataloging), the burden should be on them to
use this indicator to indicate a desire that the information NOT
display, not the other way around. In my opinion, blank should not
trigger non-display. I also think the same thing about 561. 561 is not
used for the immediate source of acquisition, but for the custodial
history of the item, something that in most cases is not *private* in
the sense that we want to protect donors or hide how much we paid for
the item or whatever. In this case, too, I feel that the burden should
be on the cataloger to say they do NOT want the field displayed, not on
the rest of us to say we DO want the field to display. I feel less
strongly about 583 and 541, but do hold the same opinion about them.
 
Anyway, though it may be after the fact, I thought this deserved
discussion here.
 
Thanks,
Bob
 
Robert L. Maxwell
Special Collections and Ancient Languages Catalog Librarian
Genre/Form Authorities Librarian
6728 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801)422-5568 ________________________________

Margaret Nichols
Head, Special Collections Materials Unit
Library Technical Services
110 Olin Library
Cornell University
Ithaca, NY. 14853-5302 
mnr1 at cornell.edu  *  Tel. (607) 255-5752 / 255-3530  *  Fax (607)
255-9524 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20071211/6928dae5/attachment.htm 


More information about the DCRM-L mailing list