[DCRM-L] 655 field -- migration

Wed May 27 19:31:18 MDT 2020

At the Beinecke we do the same. I was mistaken to say "instance" and not "occurrence." Perhaps the 655s could be sorted out on that basis.

Stephen Young

________________________________
From: DCRM-L <dcrm-l-bounces at lib.byu.edu> on behalf of Auyong, Dorothy <dauyong at huntington.org>
Sent: Wednesday, May 27, 2020 7:40 PM
To: DCRM Users' Group <dcrm-l at lib.byu.edu>
Subject: Re: [DCRM-L] 655 field -- migration

At the Huntington we only apply subfield 5 CSmH to item occurrence, not instance.

Dorothy Auyong

Early Books and Codices Cataloging Manager

Acquisitions, Cataloging & Metadata Services

The Huntington

Library, Art Museum, and Botanical Gardens

1151 Oxford Road, San Marino, CA 91108

huntington.org<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.huntington.org%2F&data=02%7C01%7Cstephen.young%40yale.edu%7C4cb2dfa787bd4b34501508d8029760fd%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262196485433439&sdata=I60vEqofI2CjxcwUQEHkoIX0P6%2BkOarRz85a%2F0QtCEE%3D&reserved=0>

T 626-405-2188

E dauyong at huntington.org<mailto:dauyong at huntington.org>

[cid:image001.png at 01D63445.86D349B0]

From: DCRM-L <dcrm-l-bounces at lib.byu.edu> On Behalf Of Young, Stephen
Sent: Wednesday, May 27, 2020 11:31 AM
To: DCRM Users' Group <dcrm-l at lib.byu.edu>
Subject: Re: [DCRM-L] 655 field -- migration

Our practice for Beinecke records is to add subfield 5 CtY-BR to those 655s that apply to instance and not work. Do others follow a similar practice?

Stephen R. Young

Rare Book Catalog Librarian

Beinecke Rare Book and Manuscript Library

________________________________

From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>> on behalf of Lapka, Francis <francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>>
Sent: Wednesday, May 27, 2020 2:20 PM
To: 'dcrm-l at lib.byu.edu' <dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>>
Subject: [DCRM-L] 655 field -- migration

Hi all.

In a 2018 report on a MARC-to-BIBFRAME data conversion executed by Casalini for Yale, a Yale TF had this to say about the 655 field:

… Conversion of the 655 field clashes with the ambiguity inherent in MARC bibliographic records; this field could map to work, instance, or item properties. To overcome MARC’s ambiguity in such fields, a converter would have to employ pattern recognition that goes beyond the MARC encoding: for example, treating all 655 fields with the value “rbprov” in subfield $2 as bf:genreForm with a domain of bf:Item. This might add considerable complexity to the conversion specification, but without this upfront complexity, the outcome will be one of diminished discovery. …

As the day nears when we may need to convert our MARC to BIBFRAME for production usage, I’m curious if other institutions have started to make plans for how to migrate 655 data to the correct Work/Instance/Item (WII) entity. In BIBFRAME, the genreForm property<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.loc.gov%2Fontologies%2Fbibframe.html%23p_genreForm&data=02%7C01%7Cstephen.young%40yale.edu%7C4cb2dfa787bd4b34501508d8029760fd%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262196485433439&sdata=tGh7GQMHGGoBncUlvJXpaXYOJRpHZUoZUIgCrla6BJ0%3D&reserved=0> can be used with work, instance, or item.  In the Library of Congress MARC-to-BIBFRAME conversion specification, the 655 field maps always to bf:Work (see this LC specification<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.loc.gov%2Fbibframe%2Fmtbf%2FConvSpec-3XX-v1.5p.xlsx&data=02%7C01%7Cstephen.young%40yale.edu%7C4cb2dfa787bd4b34501508d8029760fd%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262196485433439&sdata=8v3HmxlfmQfVif9QGgCJxa2kKNvaNVJ8v%2BcqgZUdgto%3D&reserved=0>).

Has your institution started to consider the issue? If so, what are your plans?

More questions:

  1.  Would it be acceptable to migrate all 655 data to the bf:Work?

  1.  If we’d like 655 data to migrate to Work, Instance, and Item, as appropriate, it seems that there are two broad options to consider:

     *   Leave the 655 data unchanged (from current practice) but add a considerable amount of complexity to the conversion spec to make the WII distinctions; or

     *   Adjust the 655 data in some manner before data conversion, so that WII distinctions are clearly articulated in MARC, requiring less complexity from the conversion spec.

  1.  In method A – leave the 655 data unchanged – what would be a reasonable strategy? Possibilities:

     *   Make broad mapping rules based on the thesaurus value in 655 subfield $2. For example, $2 rbprov data maps to Item (works well), $2 rbbin maps to Item (accurate more often than not), $2 gmgpc maps to Instance (mostly true), $2 rbgenr maps to Work (mostly true?), and so on.

     *   Make detailed mapping rules accounting for every expected term, e.g. Publisher’s cloth bindings maps to Instance, and so on.

Both of these possibilities assume that the converter – likely the work of a vendor – is able to incorporate such complexity.

  1.  In method B – adjust the 655 data before conversion – what’s reasonable? I can think of at least one possibility:

     *   Add a new nugget of data to the 655 entry to declare a term’s WII alignment. For example, how about a (newly defined) subfield $i? Such a subfield could align the data with WII/WEMI properties, e.g. 655 _7 $i gf-item $a Bookplates. $2 rbgenr

What are the other possibilities? What’s most likely to succeed?

Francis

Francis Lapka

Senior Catalogue Librarian

Department of Rare Books and Manuscripts

Yale Center for British Art

203-432-9672  ·  francis.lapka at yale.edu<mailto:francis.lapka at yale.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20200528/efa7d50d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9476 bytes
Desc: image001.png
URL: <http://listserver.lib.byu.edu/pipermail/dcrm-l/attachments/20200528/efa7d50d/attachment-0001.png>