[Yulcat-l] Fwd: Re: Series coding proposal

[Joan Swanekamp]

Dear cataloging colleagues,

The series of messages that is attached here is a discussion from the 
CONSER serials list related to series.  I thought many of you might find it 
interesting --- read from the bottom up.

Joan


>X-Cam-SpamDetails: Not scanned
>X-Cam-AntiVirus: No virus found
>X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
>User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
>X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 
>adultscore=0 adjust=0 reason=mlx engine=3.1.0-0606280001 
>definitions=main-0607270005
>X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0
>                          adultscore=0 adjust=0 reason=mlx
>                          engine=3.1.0-0606280001 definitions=main-0607270005
>Date:         Thu, 27 Jul 2006 14:05:23 +0100
>Reply-To: CONSER Cataloging Discussion List <CONSRLST at loc.gov>
>Sender: CONSER Cataloging Discussion List <CONSRLST at loc.gov>
>From: Hugh Taylor <jrht3 at CAM.AC.UK>
>Organization: Cambridge University Library
>Subject: Re: Series coding proposal
>Comments: To: CONSER Cataloging Discussion List <CONSRLST at loc.gov>
>To: CONSRLST at sun8.LOC.GOV
>List-Help: <http://listserv.loc.gov/cgi-bin/wa?LIST=CONSRLST>,
>            <mailto:LISTSERV at LISTSERV.LOC.GOV?body=INFO CONSRLST>
>List-Unsubscribe: <mailto:CONSRLST-unsubscribe-request at LISTSERV.LOC.GOV>
>List-Subscribe: <mailto:CONSRLST-subscribe-request at LISTSERV.LOC.GOV>
>List-Owner: <mailto:CONSRLST-request at LISTSERV.LOC.GOV>
>List-Archive: <http://listserv.loc.gov/cgi-bin/wa?LIST=CONSRLST>
>X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed)
>X-Yale-Not-Spam: For more info see: 
>http://www.yale.edu/email/spam/content.html
>X-Yale-Spam-Score:  (0)
>X-Scanned-By: MIMEDefang 2.52 on 130.132.50.7
>
>I don't wish to appear to be pouring cold water on a proposal with which I 
>have a degree of personal sympathy. And I'm conscious, since my 
>institution is neither a CONSER nor a BIBCO member, that I'm guilty of 
>trespassing. But perhaps you'll indulge me whilst I make a couple of points.
>
>1. All the discussion I've seen to date has been amongst CONSER members. 
>No harm in that, in that you're all great people, but even as a plain PCC 
>proposal the dialogue seems a bit restricted. If, as I'm seeing, there's 
>talk of taking this idea, of opening it out in the way suggested, and of 
>proposing that it be applied more widely (and possibly removing the 
>optionality?), then I'd be happier if it were to be more widely discussed 
>first.
>
>2. The proposal listed a few benefits, but I wonder how each of you is 
>planning to sell this to your managers. Here's how it might sound right now:
>
>"We're looking to simplify the way we handle description of, and access to 
>series info in our MARC records. This means that a large percentage of 
>series fields might in future be entered twice in those records, identical 
>except for the MARC coding. Yes, I know you complained last year about 
>those series where two fields are already provided with only subtle 
>differences between them; I started to explain about MARC fields 490 and 
>830, and you decided it was time for lunch... But this is different 
>because it's simpler - honest! It's just that we need to duplicate a lot 
>of information in order to achieve that simplification. It's simple 
>really. Invest to save!"
>
>Or we could try not telling the managers, on the grounds that they won't 
>listen anyway (I've had a difficult morning). Or we could hire a spin 
>doctor to sell the idea for us.
>
>Come to think of it, I *am* a manager. Whoops!
>
>Hugh
>--
>Hugh Taylor
>Head, Collection Development and Description
>Cambridge University Library
>West Road, Cambridge CB3 9DR, England
>
>email: jrht3 at cam.ac.uk   fax: +44 (0)1223 333160
>phone: +44 (0)1223 333069 (with voicemail) or
>phone: +44 (0)1223 333000 (ask for pager 036)
>
>Sue Fuller said - in whole or part - on 27/07/2006 13:19:
>>Ed's suggestion reminds me of my first impression when I read the 
>>proposal:  rather than making use of 490/830 an option for PCC records, 
>>might we consider making it standard practice? Given all the reasons that 
>>440 fields can be problematic that others have stated, is there 
>>justification for continuing to use them?  The fewer situations where we 
>>define options in our PCC practice, the more straightforward the 
>>documentation and training of new catalogers becomes.
>>We could then pursue Ed's suggestion of a MARBI proposal, with the strong 
>>evidence of our own policy adding weight to it.
>>Sue Fuller
>>
>>At 05:41 PM 7/25/2006, Ed Jones wrote:
>>>I agree that the fewer elements do "double duty" as description and
>>>access the better.  Ideally, this proposed practice could lead to a
>>>MARBI proposal covering the following points:
>>>
>>>1. Make field 440 obsolete (On existing records, change to 490 and
>>>create 830 with identical data)
>>>
>>>2. Make indicator 1 in field 490 obsolete (Delete any value from
>>>existing records).  Redefine 490 as "Series area."
>>>
>>>Ed
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: CONSER Cataloging Discussion List [mailto:CONSRLST at loc.gov] On
>>>Behalf Of Ann Ercelawn
>>>Sent: Tuesday, July 25, 2006 2:49 PM
>>>To: CONSRLST at LISTSERV.LOC.GOV
>>>Subject: Re: Series coding proposal
>>>
>>>In principle I'm strongly in favor of this (separating desc. and
>>>access), but in practice we have just asked our authorities vendor
>>>to flip 490 0s that match authority records to 440s. (Yes, we'll
>>>get a few false hits along the way).
>>>Is anyone aware of authorities vendors who can derive a new 830
>>>field (which would be preferable anyway).
>>>Ann
>>>
>>>
>>>--On Tuesday, July 25, 2006 4:40 PM -0500 "Kevin M. Randall"
>>><kmr at NORTHWESTERN.EDU> wrote:
>>>
>>> > At 02:53 PM 7/25/2006, Renette Davis wrote:
>>> >> I like it. An additional benefit is that I think it makes adding
>>> >> a series  tracing to a record for which LC has provided only a
>>> >> series statement  easier. I think it is actually easier to
>>> >> change an indicator in 490 and  add an 830 than to change a 490
>>> >> into a 440.
>>> >
>>> > Same here.  (Actually, our local catalog already has a number of
>>> > records where the 490 and 830 have identical content, because of
>>> > batch processing that converted the headings in some 830 fields.)
>>> > This is something that I was really hoping would fly the first
>>> > time it was proposed so many years ago; funny that now, instead
>>> > of being considered not as efficient, it's more efficient...
>>> >
>>> >> If the description of 490 indicator 1 can be changed from
>>> >> "traced  differently" to "traced in a different field" or
>>> >> something like that  without MARBI approval, then I withdraw my
>>> >> comment at the CONSER  Operations meeting that this needs to go
>>> >> to MARBI.
>>> >
>>> > Even if it's just the change of the description (definition?) of
>>> > an indicator, wouldn't that still need to go through MARBI?  I
>>> > can't imagine there would be much objection there, if any.
>>> >
>>> > Kevin
>>> >
>>> >
>>> >> At 01:02 PM 7/25/2006, you wrote:
>>> >>> CONSER and BIBCO colleagues, please see the series proposal
>>> >>> presented at the CONSER At-Large meeting at ALA annual:
>>> >>> http://www.loc.gov/acq/conser/SeriesProposal.pdf. The proposal
>>> >>> would allow PCC participants the option of always coding the
>>> >>> series statement in a 490 1 field and entering a controlled
>>> >>> heading in the appropriate 8XX field. Benefits include
>>> >>> facilitating local global change utilities and being able to
>>> >>> take advantage of OCLC's control headings feature.
>>> >>>
>>> >>> We felt it important to vet this change with BIBCO, CONSER, and
>>> >>> the PCC Standards Committee for further comment before making
>>> >>> this option available to PCC members.
>>> >>>
>>> >>> We've talked to the Network Development and MARC Standards
>>> >>> Office (NDMSO) about the need for MARBI approval. Our
>>> >>> understanding from NDMSO is that as the proposal states, this
>>> >>> is more a matter of program policy rather than field
>>> >>> redefinition and so probably does not require MARBI approval to
>>> >>> implement. The proposal for this practice was made several
>>> >>> years ago and though not approved at the time, it is likely
>>> >>> that libraries are making use of the practice in ILS
>>> >>> implementations.
>>> >>>
>>> >>> If adjustments to the description of 490 indicator 1 need to be
>>> >>> made, such as from "traced differently" to "traced in a
>>> >>> different field" (or similar language), this could probably be
>>> >>> incorporated as a minor editorial change in the fall 2006 MARC
>>> >>> update.
>>> >>>
>>> >>> We would like to receive your comments before September 8th,
>>> >>> 2006. Please send your comments to the listserv or feel free to
>>> >>> send comments directly to me or Carolyn Sturtevant.
>>> >>>
>>> >>> Thanks
>>> >>> Les Hawkins
>>> >>> CONSER Coordinator
>>> >>> 202 707-5185