MMG Agenda Background: Serials Control in Voyager

January 29, 2002

Ann, Joan, Marcia, Cindy Crooker (Chair Acq Group), Patricia Thurston (Chair Cat group) and Audrey recently discussed issues relating to implementing Voyager serials control (checkin) at Yale. Because we do not use the comparable module in NOTIS (lser), we do not have any serials checkin data, policies or procedures that can be migrated from our current environment to Voyager.  With serials checkin we are starting from scratch.  The question to be addressed by MMG is how should we implement serials checkin at Yale?

Online activity:
In NOTIS/Orbis we manage receipt of serials through the OPR. There we create receipt statements which, provided the bibl fixed fields are coded correctly and that there are fewer than 15 receipt lines, display in the online catalog under the label "CURRENT ISSUES".  Bound volumes coded into the MHLD record display in the online catalog under the label "LIBRARY HAS."

EXAMPLE FROM NOTIS ORBIS OPAC (modified to fit your email screen):

SML, Franke Periodical Reading Room (Non-Circulating)

Q1 +S17 (LC)

Current issues in SML Periodical Room.
(Section 7)

295:no.5552(02:Jan.4)-295:no.5553(02:Jan.11)<FROM OPR

v.1(1883)-new ser.v.166:no.3902(1969),
new ser.v.166:no.3904(1969)-new ser.v.210:no.4476(1980),
new ser.v.210:no.4478(1980)-new ser.v.250:no.4980(1990:Oct.),
new ser.v.250:no.4982(1990:Nov.)-n.s.v.282:no.5394(1998:Nov27

In Voyager, as part of data migration and conversion, our OPR receipt statements for serial records will be migrated out of the OPR record and converted into the MARC Holdings record as 866s. This conversion essentially re-creates the functionality we have in NOTIS.  See examples below:

866    |80 |a295:no.5552(02:Jan.4)-295:no.5553(02:Jan.11)<FROM OPR
866 41 |80av.1(1883)-new ser.v.166:no.3902(1969)
866 41 |80anew ser.v.166:no.3904(1969)-new ser.v.210:no.4476(1980)
866 41 |80anew ser.v.210:no.4478(1980)-new ser.v.250:no.4980(1990:Oct.)
866 41 |80anew ser.v.250:no.4982(1990:Nov.)-n.s.v.282:no.5394(1998:Nov27
866 41 |80an.s.v.282:no.5396(1998:Dec11)-n.s.v.289:no.5479(2000:Jul.28)
866 41 |80an.s.v.289:no.5481(2000:Aug.11)-n.s.v.294:no.5542(01:Oct.19)

These converted receipt statements will display in WebVoyage (OPAC) as:
Recent Issues:
295:no.5552(02:Jan.4)-295:no.5553(02:Jan.11)<FROM OPR

Older Issues: 
v.1(1883)-new ser.v.166:no.3902(1969),
new ser.v.166:no.3904(1969)-new ser.v.210:no.4476(1980),
new ser.v.210:no.4478(1980)-new ser.v.250:no.4980(1990:Oct.),
new ser.v.250:no.4982(1990:Nov.)-n.s.v.282:no.5394(1998:Nov27

Current issues in SML Periodical Room. (Section 7)

Implementing Voyager Serials Check-in at Yale:
We may continue recording serials receipts in the MFHD (MARC Holdings record) as 866s.  The work associated with creating the 866 tags is comparable to the work associated with creating OPR receipt lines in NOTIS.  The one difference is that NOTIS OPRs are created within Acquisitions, but Voyager MFHD 866s are created within the Voyager Cataloging module.  Staff accustomed to working within Acq to receive serials will need to use the Cataloging module in the future.

Fully implementing Voyager serials check-in requires considerably more work than that required to create 866 tags.  Serials checkin is part of the Voyager Acquisitions client.  Before any serials checkin can be accomplished, the title must first be represented by a purchase order. The benefits associated with using the Voyager serials control module include: better management of serials (consistent, fewer typos), automatic claiming, ability to use EDI for claiming, and interface capabilities with the new Voyager binding functions.

Voyager serials checkin records have 3 parts:
- the predictive pattern record
- the subscription record
- the checkin grids

The predictive pattern record is a template of generic enumeration and chronology descriptions. The pattern record automatically generates a prediction schedule for the issues of the subscription.  Voyager comes with approximately 200 pre-defined patterns.  Cornell has offered to share their pattern records with us which will increase the number of pre-defined patterns thus decreasing the number that we have to create.

The subscription record is the part of the serial title that is synchronized to a predictive pattern. The subscription record identifies the serial title, the component (whether it's an issue, index, supplement, etc.), the publication pattern (or whether it's non-predictive), start issue, next expected issue and claims interval.

The checkin grids pre-calculate, based on the predictive pattern and the subscription record, the next 52 issues that should arrive.  Staff use the grids to quickly receive serial publications. Grids are easily modified to reflect unexpected changes in the publication patterns.  Grids are also linked to extensive receipt and claim history.  

To implement Voyager serials control at Yale, for each serial and multi-part title, staff will need to:
1) find the related purchase order (open orders from NOTIS will be migrated)
2) locate an appropriate pattern record or create a new pattern record
3) create a subscription record to link the title to a predictive pattern
4) begin using the checkin grids to receive serials and multi-part materials.

This work is complex.  Much of it requires a high-level of bibliographic skill.  Implementing Voyager serials control at Yale raises many questions:
- Who will create pattern records when an appropriate one does not exist?
- Who will be responsible for subscription maintenance, i.e., setting up a serial for checkin?
- What level of bibliographic expertise is required to checkin material when the pattern already exists and the subscription record is already established? Does this differ based on the source of the material (e.g., for foreign language materials)?
- Who will collapse checkin records to generate MFHD (MARC Holdings record) updates?
- Our current receipt statements in the OPRs will migrate to the MFHD records in Voyager, not to checkin records. Will we attempt to convert these (manually) to checkin records? Will we conduct any kind of clean-up on these MFHD records as checkin records are created? If so, who will be responsible for updating the MFHD records?
- What staff resources are required within SML Acq to implement serials control through Voyager?
- What staff resources required within curatorial units, dept and school libraries to implement serials control?
- What level of bibliographic training (not Voyager training) is required for pattern creation and recognition, subscription maintenance, checkin, checkin collapse to MFHD, MFHD clean-up?
- To what degree should we centralize pattern creation and subscription maintenance?

Cornell reported that they temporarily re-assigned 7.0 FTE cataloging department staff to the serials control unit in order to establish pattern and subscription records for their roughly 60,000 subscriptions. More specifically, they re-assigned 15 professional and high-level C&T staff at approximately half-time for slightly more than a year.  These staff created records for everything that was received within that time period (which is some number less than 60,000).

Our Subscriptions:
See attachments from Marcia.

Options for July 2002 Implementation of Serials Checkin:

1) Each unit (SML Acq, curatorial units, school and dept libraries) implements serials checkin.  Each unit will create pattern records, subscription records and will use checkin grids.  Training in how to use the serials control module provided as part of Acq module training through Orbis2. (Who will establish policies and procedures?)

2) Phased implementation starting with SML Acq, Medical and perhaps one other unit. Endeavor provides training in use of serials control module to these units.  Together these units define policies and procedures for processing serials.  Once policies and procedures established, remaining units gradually trained.  (How long will it take to phase in remaining units? With existing staff, how many serials can we process/month? Should we look for ways, e.g., hiring additional staff, to speed up processing and the phase in of additional units?)

Return to Orbis2 Implementation Site