Re: Publication pattern - Consumer Guide (Jim Mouw) Marcia Tuttle 26 Oct 1993 11:07 UTC

---------- Forwarded message ----------
Date: Tue, 26 Oct 1993 11:21:52 +0600
From: James Mouw <mouw@MIDWAY.UCHICAGO.EDU>
Subject: Re: Publication pattern - Consumer Guide (Jim Mouw)

The 844 was not an original USMARC Holdings Format field.  My pages came
with the April 1991 revisions to the manual.

The story I am recollecting (which may be apocryphal) is that this
originated as a law library request.  The example in the manual uses two
844's, one for Decisions and one for Updates.

And, no I am not a NOTIS library, we are completely home-grown.

Jim Mouw
>This sounds pretty good!  However, I don't have an 844 field in my USMARC Hold-
>ings Format--is my face red, or what?!  Could I be behind in my updated pages?
>Please, tell me more.  [You're a NOTIS library, right?] Thanks,
>------------------------------------------------------------------------------
>.........................Gail McMillan........................
>___....____________......Serials Team Leader..................
>\  \../  ___   ___/.........University Libraries VPI&SU.......
>.\  \/  /../  /.............Blacksburg, VA - (703) 231-9252...
>..\    /../  /..............FAX (703) 231-3694................
>...\  /../  /.................................................
>....\/../__/..........INTERNET.....gmcmilla@VTVM1.CC.VT.EDU....
>......................BITNET.......gmcmilla@VTVM1.............
>----------------------------Original message----------------------------
>---------- Forwarded message ----------
>Date: Fri, 22 Oct 1993 09:09:28 +0700
>From: James Mouw <mouw@MIDWAY.UCHICAGO.EDU>
>Subject: Re: Publication pattern - Consumer Guide (Joanna Tousley-Escalante)
>
>It sounds like what Joanna is asking for is a way to maintain multiple
>check-in sequences on a single record.  One solution to that problem is to
>implement the USMARC Format for Holdings and Locations (MFHL) and to use the
>844 option.
>
>We have this up and running on our local system and it has solved many of
>our check-in problems.
>
>Basically, the 844 allows us to split a single bibliographic entity into
>multiple component parts.
>
>In our implementation the records would behave as follows:
>
>We have a single bibliographic record
>
>We have multiple holdings records attached to the bib. record, each carrying
>the same call number and copy number (we can have multiple holdings with the
>same copy number, some systems don't allow this).  Each holding record
>contains the full suite of Holdings 008, 853/854/855, 863/864/864
>combinations, etc. which reflect that component part.
>
>Each holding record also contains an 844 field identifying the component
>part that should be recorded there.  The 844 field specifications allow us
>to make up headings (within reason).  For example, we have split titles
>which produce both abstracts and indexes into two holdings records.  One 844
>will read Abstracts and the other will read Indexes.
>
>In most cases we have a single order record, attached to the bibliographic
>record.  This is where the payments reside.
>
>Claiming is prompted through each individual holding record.  In the case
>listed above, a missing abstract volume would be prompted from that 844.  We
>have a way to reference order numbers between holdings records, so the claim
>would still contain the correct order references.
>
>This has solved almost all of our difficult check-in problems.
>
>Jim Mouw
>University  of Chicago
>
>>Date: 21 Oct 1993 16:04:19 -0500
>>From: Joanna Tousley-Escalante <joanna@CCWF.CC.UTEXAS.EDU>
>>Subject: Publication pattern - Consumer Guide
>>
>>We are still in the midst of bringing up the Serials Module on our Dynix
>>system.  We've stubbed our toe on how to handle the publication pattern
>>for "Consumer Guide".  I think that somehow we need a record for what we
>>subcribe to - that is Consumer Guide.  However, there is not really a
>>thing that comes every month (week?) that is simply Consumer Guide.  It
>>comes as it's many sub-series and special issues.  There appears to be no
>>running number at any level that identifies each issue as the next
>>expected number for Consumer Guide.
>>
>>We have also, long before this era of having an online serials control
>>system, cataloged many of the individual titles as such - New Car Guide,
>>Used Car Guides, etc.  The public service staff like very much having the
>>separate titles entered as separate titles for search and retrieval
>>purposes.  It's almost like subscribing to a small collection of serials
>>by subscribing to one mega title.
>>
>>Have others of you on any serials system been able to define a workable
>>solution that fits all of the questions for this title?  a.) serials
>>checkin, b.) serials invoicing, c.) serials subscription and renewals, and
>>the final question of c.) serials cataloging?  Can we have one solution
>>for all the component parts?  Should we keep a kardex handy?
>>
>>You can answer me at my personal address listed below.  Thanks to you all
>>for your support and dialogue on SERIALST!
>>
>>                                     Cordially,
>>                                     Joanna Tousley-Escalante
>>                                     Austin Community College
>>                                     internet:  joanna@ccwf.cc.utexas.edu
>>                                     fax:       512/483-7773
>>
>>
>
>