---------- 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 >> >> > >
