[DCRM-L] 655 field -- migration

Fri May 29 16:29:08 MDT 2020

Hi Francis,

at the Ransom Center we have started kind of similar conversations but from the angle of original BIBFRAME metadata creation. As members of the LD4P2 cohort (and in the context of the current shelter-at-home situation) we are spending a good chunk of our time "re-cataloging" one of our collections in the RDF based cataloging platform developed for the project.

To your first question, we early on decided on assigning the proper genre/form term to the proper BF entity, and that would be our expectation for a programmatic conversion. That said, while the parsing is obvious for what goes to the item, it might not be so obvious sometimes (even for human eyes!) for what goes to the Work or Instance, since it depends on the nature of the work/expression.

To your second question, even though we haven't discussed this yet at the center, I would always feel more inclined towards Method B (adjust 655 to potential mapping). In my experience, you might lose some crucial data post migration that could have been very helpful for data remediation decisions. That said, your question made me curious about the likeability of approach A working for us (leaving the 655 unchanged), so I had a quick look at our use of the 655 field throughout time. Of the 34,500 occurrences of the field 655 in our catalog, there are around 50 different values on the $2, reduced to 29 after some quick OpenRefine magic. More than half are "rbgenr" terms, with "fast", "aat", "rbbin", "gsafd" and "lcgft" being the only ones with more than a thousand occurrences. Honestly, the only ones of these I would feel confident to assign programmatically based on source are "rbbin" and "gsafd". On the other hand, our use of $5 is very recent, so that would not work for our legacy data either. As per a conversion based on pattern recognition, well, we might have up to seven different variations for a given vocabulary term (typos, plural/singular, etc..), so that approach will have to be preceded by  some heavy pre-migration data clean up or be extremely complex.

The idea of implementing a new subfield to indicate corresponding BF entities sounds very interesting and I would like to hear more about logistics or drawbacks for that approach. For instance, how would that new field impact data display in our current ILS/LSPs (assuming that those data manipulations would get started well in advance before migration to BIBFRAME)? I also would be interested in further discussions around the challenge of associating any copy specific access point (not just genre/form but former owners, annotators, inscribers, etc..) to the actual item when there are many items to one manifestation description.

Anyway, I better stop before I get too much into the weeds, but hope any of this helped. I am excited to see this conversation getting started and would also love to hear use cases and thoughts from other institutions!

Happy Friday!
Paloma

Paloma Graciani Picardo| she, her, hers
Metadata Librarian and Head, Printed & Published Media
Harry Ransom Center | The University of Texas at Austin
www.hrc.utexas.edu<http://www.hrc.utexas.edu/>

From: DCRM-L <dcrm-l-bounces at lib.byu.edu> On Behalf Of Lapka, Francis
Sent: Thursday, May 28, 2020 7:28 AM
To: DCRM Users' Group <dcrm-l at lib.byu.edu>
Subject: Re: [DCRM-L] 655 field -- migration

Thanks Stephen, Dorothy, and Jeff for your responses.

I think my original query has taken an inadvertent detour. It wasn't my intent to question the well-established practice of using subfield $5 in conjunction with 655 fields to indicate that a form/genre term applies to a specific copy. This is good and proper.

The main thrust of my question is this: when we reach the day when our catalogs are batch converted from MARC to BIBFRAME, how can we apply a machine-actionable mechanism (without human mediation) to ensure that the 655 headings are appropriately mapped to the pertinent items, instances, and works?

Certainly the presence of a subfield $5 is already a machine-actionable clue that a given 655 heading should be matched with an item (though it's regrettable that subfield $5 specifies an institution instead of an actual copy - esp. when there's more than one copy). But in current practice, there's no explicit indication whether a term should be matched to an instance (manifestation) or a work. What's the best way to plan for batch conversion processes that correctly identify the proper domain for all 655 headings?

Francis

From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>> On Behalf Of Jeff Barton
Sent: Wednesday, May 27, 2020 10:05 PM
To: DCRM Users' Group <dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>>
Subject: Re: [DCRM-L] 655 field -- migration

We code as $5 (NjP) 655 entries (and the accompanying 500 field notes) that refer to aspects at the item level - or "copy specific" in bibliographicese.  These are generally unique to the copy at hand.  The exception among the RBMS thesauri would be terms from the Genre thesaurus terms, which apply more broadly to the work.  I'd be interested in what others do in this regard too.

In that general connection, I'd also be interested to know how others are generally using sub-field divisions Form/Genre terms.  I seem to recall from MidWinter that many were subdividing chronologically only by century.  Is that an accurate recollection?  I'd also be interested in if/how others might be subdividing 655 terms geographically, and if so at what level":  city, state/province/county, or country? If geographic aspects (inscriptions or bookseller tickets, for instance) can be reasonably identified with a location, that is.

Thanks

Jeff Barton

Cotsen Library Cataloger

Rare Books & Special Collections Department

Princeton University Library

One Washington Rd.

Princeton, NJ 08544

jpbarton at princeton.edu<mailto:jpbarton at princeton.edu>

________________________________
From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto:dcrm-l-bounces at lib.byu.edu>> on behalf of Young, Stephen <stephen.young at yale.edu<mailto:stephen.young at yale.edu>>
Sent: Wednesday, May 27, 2020 9:31:18 PM
To: DCRM Users' Group <dcrm-l at lib.byu.edu<mailto:dcrm-l at lib.byu.edu>>
Subject: Re: [DCRM-L] 655 field -- migration

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<mailto:dcrm-l-bounces at lib.byu.edu>> on behalf of Auyong, Dorothy <dauyong at huntington.org<mailto:dauyong at huntington.org>>
Sent: Wednesday, May 27, 2020 7:40 PM
To: DCRM Users' Group <dcrm-l at lib.byu.edu<mailto: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%7Cfrancis.lapka%40yale.edu%7C5d4925d42b6846c6d98408d802ab9f6e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262283435350119&sdata=%2FD6aFarZljoOOL5ed%2Bi%2FOcUq%2BYUnc0sgUiIJqFAka0g%3D&reserved=0>

T 626-405-2188

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

[cid:image002.png at 01D635DB.1263AB00]

From: DCRM-L <dcrm-l-bounces at lib.byu.edu<mailto: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<mailto: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%7Cfrancis.lapka%40yale.edu%7C5d4925d42b6846c6d98408d802ab9f6e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262283435360114&sdata=qSzjUVTA6y%2BDJKN3%2FVO%2F5YEng2ykRQdQrAfWUWQSn4E%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%7Cfrancis.lapka%40yale.edu%7C5d4925d42b6846c6d98408d802ab9f6e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262283435370107&sdata=kFSzZ54FyC%2BnH7fiW%2BcP6JT2h53JOLp2PFC11H7V0nI%3D&reserved=0>).

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