$i is required in linking entry fields? Kay Teel (22 May 2013 19:45 UTC)
Re: $i is required in linking entry fields? Mike Saunders (22 May 2013 20:00 UTC)
Re: $i is required in linking entry fields? Kevin M Randall (22 May 2013 20:39 UTC)
Re: $i is required in linking entry fields? Mike Saunders (23 May 2013 12:58 UTC)
Re: $i is required in linking entry fields? Tarango, Adolfo (23 May 2013 14:54 UTC)

Re: $i is required in linking entry fields? Mike Saunders 23 May 2013 12:58 UTC

I can understand the concept for using this when serial titles are merged or absorbed but the 580 note seems to work just fine in these situations. When MARC is no longer used, it may make sense to change the way these relationships are presented to the user. What worries me is when you say you were "rushed for time" and "there wasn't a lot of time for discussion" at the CONSER meeting. Maybe CONSER should make time to investigate the implications of changes before making them!!!!!!!!!!!!!!!

Mike Saunders,

Serials Officer,

National Gallery of Canada

380 Sussex Drive

PO Box 427, Station A,

Ottawa, Ontario

K1N 9N4

-----Original Message-----
From: SERIALST: Serials in Libraries Discussion Forum [mailto:SERIALST@list.uvm.edu] On Behalf Of Kevin M Randall
Sent: Wednesday, May 22, 2013 4:39 PM
To: SERIALST@LIST.UVM.EDU
Subject: Re: [SERIALST] $i is required in linking entry fields?

Kay Teel wrote:

> In the newly released PCC guidelines for relationship designators
> http://www.loc.gov/aba/pcc/rda/PCC%20RDA%20guidelines/Relat-Desig-
> Guidelines.docx),
> Guideline 14 says: "If a cataloger wishes to indicate a known
> relationship to a known resource, and the $i relationship information
> subfield is defined for the  MARC 7XX field being used, provide a
> relationship designator. Do so even if the field coding otherwise
> already expresses a relationship."
>
> This sounds like it is now required of PCC (CONSER) records to include
> $i in 76x-78x linking fields, for example:
> 780 00 $i Continues (work): $t Regional trends (London, England)
> 785 00 $i Continued by (work): $t Region and country profiles
>
> Are mergers coded as:
> 785 00 $i Merged with: $t American electrician
> 785 00 $i To form: $t Electrical world (New York, N.Y. : 1906) ?
>
> We wanted to confirm that this is now required and to be implemented
> immediately. Although my library doesn't participate in CONSER, we
> generally follow CONSER cataloging standards.

This was one of many issues on the agenda at the recent BIBCO/CONSER Operations Committee meeting.  That was a packed agenda, without a lot of time for discussion, unfortunately.  My recollection is that this was one of the items that, while it didn't have a lot of agreement on the current details, there was agreement that we should go ahead and start using the guidelines, and our experience along the way will help us determine what changes we need to make in the future.

The purpose and function of relationship designators in MARC are not all that clear.  Are they meant for machine functioning, OPAC display, or both?  If OPAC display is part of it, there is a problem with fields 780 and 785, since there is no indicator defined for suppressing a display constant in favor of using text in subfield $i.  Also, I am not aware of any OPAC applications that are able to generate accurate notes from 785 fields in merger situations; throwing subfield $i into it just turns them into a bunch of nonsense.

My personal opinion is that we need to make records that function correctly in our current catalogs.  In some situations, using subfield $i will impede that functionality, so I will certainly not be using it in our local database in those cases.  I haven't yet had to make a decision in regard to the CONSER master record in OCLC...

Kevin M. Randall
Principal Serials Cataloger
Northwestern University Library
kmr@northwestern.edu
(847) 491-2939

Proudly wearing the sensible shoes since 1978!

***********************************************
* You are subscribed to the SERIALST listserv (Serials in Libraries discussion forum)
* For additional information, see  the SERIALST Scope, Purpose and Usage Guidelines <http://www.uvm.edu/~bmaclenn/serialst.html>
***********************************************

***********************************************
* You are subscribed to the SERIALST listserv (Serials in Libraries discussion forum)
* For additional information, see  the SERIALST Scope, Purpose and Usage Guidelines <http://www.uvm.edu/~bmaclenn/serialst.html>
***********************************************