[DCRM-L] Alma, Special Collections and moving to a single, shared record

[Will Evans]

Hi Amy,



Is there any way to protect your data enhancements by coding the 040 with
“$e dcrmb” or any its of forerunners?



Best,

Will





*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*

Will Evans

National Endowment for the Humanities

Chief Librarian in Charge of Technical Services

Library of the Boston Athenaeum

10 1/2 Beacon Street

Boston, MA   02108



Tel:  617-227-0270 ext. 243

Fax: 617-227-5266

www.bostonathenaeum.org





*From:* DCRM-L [mailto:dcrm-l-bounces at lib.byu.edu] *On Behalf Of *Amy
Robertson
*Sent:* Friday, February 02, 2018 8:07 AM
*To:* DCRM Users' Group
*Subject:* [DCRM-L] Alma, Special Collections and moving to a single,
shared record



Hello all --

I'm not sure if this question is appropriate here but I'm hoping those with
more experience than me will have some thoughts on this problem.


We are part of a consortium about to migrate to Alma and to a single
record. The single record, called the master record, is determined by the
record load. Each institution's records are loaded one by one into the
shared catalog called the Network Zone. The master record is the first
unique OCLC record loaded -- subsequent copies are linked to the master
record. No fields from the subsequent copies are retained unless they are
tagged $9 LOCAL Our institution's records will be loaded 7th -- so we will
have many instances where just our holdings will be linked and our original
bib will not be loaded.



We are concerned that we will lose enhancements, especially in our special
collections records, and especially those for rare books from the hand
press era, (as well as any records we add post migration).



As an example, we might have a record in our current ILS that is a match to
an OCLC record but has been enhanced by our cataloger with both local notes
unique to our copy as well enhancements that apply to the work as a whole.



As I mentioned above, truly local notes are protected with $9 LOCAL but the
other enhancements would not be.



If a record is migrated into the Network Zone, other institutions who have
the same title can change any field that doesn't have the $9 LOCAL or they
may choose to overlay the record. In such a case, enhancements that aren't
local notes would be lost such as:



*245 -- original OCLC title was abridged -- cataloger extended the
transcription*

*264 -- cataloger extended transcription to include publisher's address
from the title page*

*546 -- language note added*

*505 -- cataloger added contents from the title page *

*Signature statement added*

*Genre headings added*

*Additional subject headings added*

*Access point for publisher added*

*752 -- hierarchical place name added*



We have confirmed through Ex Libris that there is no way to protect these
fields in the Network Zone. An option that has been suggested is to move
the 035 OCLC data into another field thereby preventing the records we are
concerned about from being loaded into the Network Zone. If this happens,
the records can only be viewed by searching our institution's instance of
Alma -- a consortium search would not return these records. This isn't
ideal since we would like to have maximum exposure for these unique
materials.



It seems to boil down to either we:



--load the records into the Network Zone but lose any enhancements we've
made to records that don't fall under $LOCAL



OR



-- load the records only into the Institution Zone and lose Network Zone
exposure for the materials

There has also been the suggestion to reload our records into OCLC since
having OCLC numbers that don't overlap with other records in our consortium
would ensure that our special collections records would be "master" records
in the shared Network Zone. But this seems like bad OCLC practice.



Has anyone encountered this situation or have any thoughts on it?

Thanks in advance for any advice!



-- 

Amy Robertson

Coordinator of Original Cataloging

American University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20180202/9078f832/attachment-0001.html>