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

Wed Feb 7 09:10:30 MST 2018

A thought from a naïve observer:

If the choice is between keeping your enhanced rare materials data in the record but losing wider distribution, or having wider distribution but losing pertinent data, I'd go with the former. Once it's gone, it's gone, and there may be a way in the future to have your unmerged records in the Network Zone (whatever that is). Or even possibly now, if I'm reading Christine's post correctly.

Deborah J. Leslie | Folger Shakespeare Library | djleslie at folger.edu |

From: DCRM-L [mailto:dcrm-l-bounces at lib.byu.edu] On Behalf Of Christine DeZelar-Tiedman
Sent: Wednesday, 07 February, 2018 09:02
To: DCRM Users' Group
Subject: Re: [DCRM-L] Alma, Special Collections and moving to a single, shared record

We migrated from Aleph to Alma in 2013 without merging our bib records. We merged many of our holdings records, but exempted serials and special collections materials. During the preparation for migration, Ex Libris strongly encourages merging of bib and holdings records, and may make it sound like you "have" to do it, but if your institution is able to make the case why certain categories of materials shouldn't be merged, they won't make you do it. At least that was our experience in 2013.

On Tue, Feb 6, 2018 at 9:02 AM, Tedford, Beth <tedforme at wfu.edu<mailto:tedforme at wfu.edu>> wrote:
I am a rare books copy cataloger at a university library, and have been following this discussion with much interest. We are a Voyager library, but within 3 years or so we are more than likely moving to Alma. We have concerns as well about merging the records. In Voyager we have separate records for all our material because of all the descriptive information in our bib records. However, it has been explained to us that we will need to merge all our records with the general stacks copies where we overlap before moving to Alma. Am I understanding it correctly that there is a way to NOT merge records in Alma? This would be our ideal situation if that was possible. Any information will be greatly appreciated.

On Tue, Feb 6, 2018 at 9:01 AM, Christine DeZelar-Tiedman <dezel002 at umn.edu<mailto:dezel002 at umn.edu>> wrote:
Further clarification of U of MN's situation--while we share records among the U of Mn campuses, we do not use the Network zone for this--our records are in the Institution zone. Only e-resource records are in the Network zone. So it's not analogous to Amy's situation.

On Fri, Feb 2, 2018 at 11:09 AM, Claire Stuckey <c-stuc1 at umn.edu<mailto:c-stuc1 at umn.edu>> wrote:
Hello Amy,
I wasn't involved directly with our migration to Alma, but I consulted with our other cataloger here, Sarah Yates, who was; she replied: "We didn't have to deal with anything like this since we didn't merge records when we migrated to Alma (thank goodness). Has anyone so far suggested that she try to arrange for her library's special collections records to load first instead of seventh? Maybe the order is already set in stone, but that's the only thing I can think of other than the imperfect options she already mentions in her question."

I'll just clarify that before Alma, the law library at U of MN did not share records with the other campus libraries so it's possible we were in a unique position to be able to have more control. We do share records/bibliographic records now, but not for our rare collections.

Claire

On Fri, Feb 2, 2018 at 8:41 AM, Amy Robertson <dawson at american.edu<mailto:dawson at american.edu>> wrote:
Hi Will --
Thanks for the suggestion. It's possible coding the 040 might provide some restrictions but we are still pretty far from understanding the various limits that are possible in the admin settings. If it is possible it would only protect the records we didn't overlap with -- unfortunately we have been unable to find out how many will overlap with the records that are loaded prior to ours.

On Fri, Feb 2, 2018 at 9:01 AM, Will Evans <evans at bostonathenaeum.org<mailto:evans at bostonathenaeum.org>> wrote:
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<https://maps.google.com/?q=10+1/2+Beacon+Street+Boston,+MA%C2%A0%C2%A0+02108&entry=gmail&source=g>
Boston, MA   02108<https://maps.google.com/?q=10+1/2+Beacon+Street+Boston,+MA%C2%A0%C2%A0+02108&entry=gmail&source=g>

Tel:  617-227-0270 ext. 243<tel:(617)%20227-0270>
Fax: 617-227-5266<tel:(617)%20227-5266>
www.bostonathenaeum.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bostonathenaeum.org_&d=DwMFaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r=Ccmr2OuUJ8eW2hnxd74xaNcyu_MTx_PDxUlbVFcpDOQ&m=GyepDiGFsDUJRZ0mOcDfl9vVHcIaaKHxdrOrt4aW7JE&s=EH9ZA-FAcPV2oKJSPzp3TwLRE2lOQYTAkYxbtqmCGK8&e=>

From: DCRM-L [mailto:dcrm-l-bounces at lib.byu.edu<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

--
Amy
Cataloging Services Unit
202-885-3568<tel:(202)%20885-3568>

--
Claire M. Stuckey, M.A., LPCC, NBC-HWC
Library Program Specialist I, U of MN Law Library
229 19th Ave. S., #120, Minneapolis, MN 55455<https://maps.google.com/?q=229+19th+Ave.+S.,+%23120,+Minneapolis,+MN+55455+612&entry=gmail&source=g>
612-624-7536<tel:(612)%20624-7536> law.umn.edu/library<http://law.umn.edu/library>

Graduate Faculty & Advisor, U of MN Earl E. Bakken Center for Spirituality & Healing
420 Delaware St. SE, Minneapolis, MN 55455<https://maps.google.com/?q=420+Delaware+St.+SE,+Minneapolis,+MN+55455&entry=gmail&source=g>
Office hrs: By appt. c-stuc1 at umn.edu<mailto:c-stuc1 at umn.edu> 612-490-6761<tel:(612)%20490-6761> csh.umn.edu<http://csh.umn.edu>

--
Christine DeZelar-Tiedman
Metadata and Emerging Technologies Librarian
University of Minnesota Libraries
160 Wilson Library
309 19th Ave. S.                        <https://maps.google.com/?q=309+19th+Ave.+S.+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+Minneapolis,+MN+55455(612&entry=gmail&source=g>
Minneapolis, MN 55455
(612) 625-0381<tel:(612)%20625-0381>
dezel002 at umn.edu<mailto:dezel002 at umn.edu>

--
Beth Tedford, MLIS
Special Collections & Archives Assistant
Rare books cataloger
Z. Smith Reynolds Library
Wake Forest University
PO Box 7777
Winston-Salem, NC 27109
336-758-4657<tel:(336)%20758-4657>
tedforme at wfu.edu<mailto:tedforme at wfu.edu>
Defender of Wonders

--
Christine DeZelar-Tiedman
Metadata and Emerging Technologies Librarian
University of Minnesota Libraries
160 Wilson Library
309 19th Ave. S.
Minneapolis, MN 55455
(612) 625-0381
dezel002 at umn.edu<mailto:dezel002 at umn.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20180207/2ecc9cae/attachment-0001.html>