[DCRM-L] A Holdings 655

Fri May 31 00:44:26 MDT 2024

Hi all

I agree it makes sense as long as it's indexable. Alma is fairly flexible in its metadata configuration. It already has all the local field options (anything with a 9 in it) available to turn on in the Alma search index, however I know less about exposing holdings MARC data to the discovery layer.

Related to this, I thought I'd note a word of caution specific to Alma holdings records - where multiple unique holdings records exist, Alma has a tendency to ditch holdings records it doesn't think it needs when moving items between locations, depending on the method you use. It won't preclude you using them, but it's worth being aware of its behaviour when it's being too clever for its own good: Avoiding lost holdings data when moving items to a new permanent location - Ex Libris Knowledge Center (exlibrisgroup.com)<https://knowledge.exlibrisgroup.com/Alma/Community_Knowledge/Avoiding_lost_holdings_data_when_moving_items_to_a_new_permanent_location>

For simplicity's sake, we put provenance and other copy-specific notes in bibliographic and item records rather than the holdings record, but I recognise this would probably be less sustainable for larger institutions/collections than us.

Kind regards
Jonah Highman (he/him)
Librarian (Collection and Access Services)
University Library  *  M209, Perth WA 6009 Australia
+61 8 6488 3752  *  jonah.highman at uwa.edu.au<mailto:jonah.highman at uwa.edu.au>
[The University of Western Australia]<https://www.web.uwa.edu.au/university-campaigns-resources/emailsig2015/uwa-logo>
[UWA on Facebook]<https://www.uwa.edu.au/university-campaigns-resources/emailsig2015/facebook>  [UWA on X] <https://www.uwa.edu.au/university-campaigns-resources/emailsig2015/twitter>   [UWA on Youtube] <https://www.uwa.edu.au/university-campaigns-resources/emailsig2015/youtube>   [UWA on Linked In] <https://www.web.uwa.edu.au/university-campaigns-resources/emailsig2015/linkedin>   [UWA on Instagram] <https://www.web.uwa.edu.au/university-campaigns-resources/emailsig2015/instagram>
[cid:image008.png at 01DAB361.F6AF8AB0]

[cid:image010.png at 01DAB361.F6AF8AB0]
We acknowledge we are situated on Noongar land, and that Noongar people remain the spiritual and cultural custodians of their land, and continue to practise their values, languages, beliefs and knowledge. We pay our respects to the traditional owners of the lands on which we live and work across Western Australia and Australia.

From: DCRM-L <dcrm-l-bounces at lib.byu.edu> On Behalf Of Erin Blake via DCRM-L
Sent: Tuesday, May 28, 2024 11:32 PM
To: DCRM-L (dcrm-l at lib.byu.edu) <dcrm-l at lib.byu.edu>
Cc: Erin Blake <EBlake at FOLGER.edu>
Subject: Re: [DCRM-L] A Holdings 655

I'm late to the game on this.... A system upgrade bumped DCRM-L off my 'favorites' list and I hadn't realized I was missing the conversation!

I think 655 in the Holdings format makes excellent logical sense, assuming it can be indexed properly.

Our TIND ILS provides the equivalent already, thanks to having holdings data "embedded" in the bib record. We can use $8 to link particular headings to a particular copy (not just 655s but also copy-specific 5XX and 7XX fields).

Scroll down to the bottom of https://catalog.folger.edu/record/162814 for an example: copy 1 has copy-specific 655s, copy 2 has a 700 for former owner.

Erin

---------------------
Erin Blake, PhD | Senior Cataloger | she/her | Folger Shakespeare Library | eblake at folger.edu<mailto:eblake at folger.edu>

From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>> On Behalf Of Lapka, Francis via DCRM-L
Sent: Friday, May 17, 2024 10:27 AM
To: DCRM Users' Group <dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>>
Cc: Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>>
Subject: Re: [DCRM-L] A Holdings 655

Bob, you rightly highlight questions related to how systems would handle a Holdings 655. I wonder if the problem is chicken-and-eggy: perhaps our systems are weak in this domain because our expectations have always been too low.

The Yale context includes a migration to Alma in 2025 and a concurrent review of practices for copy-specific data. For indexing and display, we plan on maintaining a Blacklight-based catalog, which gives us more control for customized outcomes. For cataloging, you'd want a Holdings-based genre/form field to be controllable, like access points in a Bib record. A little bit of tinkering in our Alma sandbox suggests we could do this by making use of Alma's Controlled Vocabulary Registry<https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/Metadata_Management/210Metadata_Management_Configuration/Configuring_Cataloging#Configuring_Controlled_Vocabulary_Registry>. So the elements seem there to make a Holdings 655 feasible and useful, here at least. But I'd hesitate to propose a new MARC field in the absence of wider interest.

I share your interest in former owner access points in Holdings. Here I think the recently introduced 361 field<https://www.loc.gov/marc/holdings/hd361.html> could suffice, even if the structures don't exactly parallel the 7xx fields.

Francis

From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>> On Behalf Of Robert Maxwell via DCRM-L
Sent: Thursday, May 16, 2024 5:27 PM
To: DCRM Users' Group <dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>>
Cc: Robert Maxwell <robert_maxwell at byu.edu<mailto:robert_maxwell at byu.edu>>
Subject: Re: [DCRM-L] A Holdings 655

I think that sounds like a good idea but I don't think our system (or any other?) would index it, which is important. But maybe that could be overcome. Actually it would also be nice if holdings records could contain "local" added access points, e.g. for former owners. With the same caveat, needs to index.

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.
From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>> On Behalf Of Lapka, Francis via DCRM-L
Sent: Thursday, May 16, 2024 1:24 PM
To: DCRM Users' Group <dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>>
Cc: Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>>
Subject: [DCRM-L] A Holdings 655

Two questions:

  1.  If the MARC Holdings format included a field 655 for copy-specific genre/form terms, such as those in the Provenance facet of the RBMS CV<https://id.loc.gov/vocabulary/rbmscv/cv00017.html>, would your library think about using it?

  1.  Would the MARC community scoff at a proposal for such a field?

Francis

Francis Lapka
Senior Catalog Librarian
Department of Rare Books and Manuscripts
Yale Center for British Art
203-432-9672  *  britishart.yale.edu<http://britishart.yale.edu/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3605 bytes
Desc: image001.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3444 bytes
Desc: image002.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2371 bytes
Desc: image003.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 10260 bytes
Desc: image004.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 3474 bytes
Desc: image005.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 3474 bytes
Desc: image006.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 3545 bytes
Desc: image007.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 8883 bytes
Desc: image008.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 1001 bytes
Desc: image009.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 12948 bytes
Desc: image010.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20240531/317240f6/attachment-0019.png>