<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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?</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Stephen R. Young</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Rare Book Catalog Librarian</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Beinecke Rare Book and Manuscript Library</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> DCRM-L <dcrm-l-bounces@lib.byu.edu> on behalf of Lapka, Francis <francis.lapka@yale.edu><br>
<b>Sent:</b> Wednesday, May 27, 2020 2:20 PM<br>
<b>To:</b> 'dcrm-l@lib.byu.edu' <dcrm-l@lib.byu.edu><br>
<b>Subject:</b> [DCRM-L] 655 field -- migration</font>
<div> </div>
</div>
<style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:Calibri}
@font-face
        {font-family:"Calibri Light"}
@font-face
        {font-family:"Georgia Pro"}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
        {color:#0563C1;
        text-decoration:underline}
a:visited, span.x_MsoHyperlinkFollowed
        {color:#954F72;
        text-decoration:underline}
p.x_MsoListParagraph, li.x_MsoListParagraph, div.x_MsoListParagraph
        {margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif}
span.x_EmailStyle17
        {font-family:"Georgia Pro",serif;
        color:windowtext}
.x_MsoChpDefault
        {}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
        {}
ol
        {margin-bottom:0in}
ul
        {margin-bottom:0in}
-->
</style>
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="x_WordSection1">
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">Hi all.</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">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:</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal" style="margin-left:.5in">… 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. …</p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">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 <a href="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%7C389a3e900933450aced108d8026aa87b%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262004405567746&sdata=2dFJ3vxu3EN1VLH8tok8lptlTrLQ%2FxtU81a31iTZctA%3D&reserved=0" originalsrc="http://id.loc.gov/ontologies/bibframe.html#p_genreForm" shash="QP5L+7uFYIlgA4+DhEoX72RKXdbKwKkahVDFOZPE+MDNUyvLqDmosfzMFvL16V+IPGqTd6v/nwxO6+vWME4v5HseUeOqFyyw5Zg31P14hdgPJ46iRFEoLD4tz5xqSUp7FKPiEfeE4IwKa5vInvf5H/I/W4c6PyMQ4aZL6vdSgqY=">
genreForm property</a> 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
<a href="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%7C389a3e900933450aced108d8026aa87b%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C1%7C637262004405577739&sdata=R70CvgK1eCUM%2FOYNPFjkik%2FZohN84BR4J0uvd%2BlgwZo%3D&reserved=0" originalsrc="https://www.loc.gov/bibframe/mtbf/ConvSpec-3XX-v1.5p.xlsx" shash="KB8Bmqhz7nOTfZk1HPI2L0WiBTM8SQS2eMHL+kbjS5qKKYll6IFB/3+PW9g45zNUOA0HhfVDpLLYCW9QRiNtLRslDjxW3AdIaY01LoVxg/bRWXrPhILcEhmAa+gCV+sAFYm56937aOz9zAyFW/EJZrrgIkoSPLbs7yGnx3Pz5ls=">
this LC specification</a>). </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">Has your institution started to consider the issue? If so, what are your plans?
</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">More questions:</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="1" type="1" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level1 lfo1"><span style="font-family:"Georgia Pro",serif">Would it be acceptable to migrate all 655 data to the bf:Work?</span></li></ol>
<p class="x_MsoListParagraph"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="2" type="1" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level1 lfo1"><span style="font-family:"Georgia Pro",serif">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:</span></li></ol>
<p class="x_MsoListParagraph"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="2" type="1" style="margin-top:0in">
<ol start="1" type="a" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level2 lfo1"><span style="font-family:"Georgia Pro",serif">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</span></li></ol>
</ol>
<p class="x_MsoListParagraph" style="margin-left:1.0in"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="2" type="1" style="margin-top:0in">
<ol start="2" type="a" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level2 lfo1"><span style="font-family:"Georgia Pro",serif">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.</span></li></ol>
</ol>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="3" type="1" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level1 lfo1"><span style="font-family:"Georgia Pro",serif">In method A – leave the 655 data unchanged – what would be a reasonable strategy? Possibilities:</span></li></ol>
<p class="x_MsoListParagraph"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="3" type="1" style="margin-top:0in">
<ol start="1" type="a" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level2 lfo1"><span style="font-family:"Georgia Pro",serif">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.</span></li></ol>
</ol>
<p class="x_MsoListParagraph" style="margin-left:1.0in"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="3" type="1" style="margin-top:0in">
<ol start="2" type="a" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level2 lfo1"><span style="font-family:"Georgia Pro",serif">Make detailed mapping rules accounting for every expected term, e.g. Publisher’s cloth bindings maps to Instance, and so on.
</span></li></ol>
</ol>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoListParagraph" style="margin-left:1.0in"><span style="font-family:"Georgia Pro",serif">Both of these possibilities assume that the converter – likely the work of a vendor – is able to incorporate such complexity.</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="4" type="1" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level1 lfo1"><span style="font-family:"Georgia Pro",serif">In method B – adjust the 655 data before conversion – what’s reasonable? I can think of at least one possibility:</span></li></ol>
<p class="x_MsoNormal" style="margin-left:.5in"><span style="font-family:"Georgia Pro",serif"> </span></p>
<ol start="4" type="1" style="margin-top:0in">
<ol start="1" type="a" style="margin-top:0in">
<li class="x_MsoListParagraph" style="margin-left:0in; mso-list:l0 level2 lfo1"><span style="font-family:"Georgia Pro",serif">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</span></li></ol>
</ol>
<p class="x_MsoListParagraph" style="margin-left:1.0in"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">What are the other possibilities? What’s most likely to succeed?</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif">Francis</span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Georgia Pro",serif"> </span></p>
<p class="x_MsoNormal"><span style="font-family:"Calibri Light",sans-serif">Francis Lapka</span></p>
<p class="x_MsoNormal"><i><span style="font-family:"Calibri Light",sans-serif">Senior Catalogue Librarian</span></i></p>
<p class="x_MsoNormal"><span style="font-family:"Calibri Light",sans-serif">Department of Rare Books and Manuscripts</span></p>
<p class="x_MsoNormal"><span style="font-family:"Calibri Light",sans-serif">Yale Center for British Art</span></p>
<p class="x_MsoNormal"><span style="font-family:"Calibri Light",sans-serif">203-432-9672  · 
</span><a href="mailto:francis.lapka@yale.edu"><span style="font-family:"Calibri Light",sans-serif; color:blue">francis.lapka@yale.edu</span></a><span style="font-family:"Calibri Light",sans-serif"></span></p>
<p class="x_MsoNormal"> </p>
</div>
</div>
</body>
</html>