[OPEN-ILS-DEV] Serials patch RFC

[Frances Dean McNamara]

I have a general question about the development for serials.  This looks like it is addressing holdings statements for serials, and then issues as they come in.

The other aspect is bound volumes, that the summary holdings statements represent.  For us, these are bound volumes that each have a barcode and we frequently allow the volumes to circulate.  So we might have 120 bound volumes, then 6 recently checked in issues.  The opac will say we have v. 1-56, 60-124  and the 6 issues.  But we also actually list out the items with the volume numbers so folks can see which are available and which are checked out.  It does seem to me, that the current structure of the asset.call_number and asset.copy don't accommodate that very well because you really need to have a call number, a copy number, and then individual volume numbers.  Currently I think the volume number has to be part of the call no. and that makes for a separate row for every volume.  Seems like maybe you need separate places in asset.copy  for the copy number and volume numbers.

Is there any plan to address that?  In our collection long runs of serials are very important as people are looking at citations to v.26, Feb. 1907 p. 56-89    or something like that.

I will look at the specifics of the current design as well.  It is certainly helpful for us to have a null end date for a subscription as we do not actually renew each year.  We keep it open till we cancel the subscription and it would not work for us to be forced to renew every year.  Thanks.

Frances McNamara
University of Chicago

-----Original Message-----
From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Dan Scott
Sent: Sunday, March 22, 2009 9:22 AM
To: Evergreen Development Discussion List
Subject: [OPEN-ILS-DEV] Serials patch RFC

I've built up enough local code over the last couple of days that I wanted to post the current patch to the list for comments.

The attached patch does the following:

Extends and modifies the serials schema:
  * adds a serial.record_entry (sre) and associated serial.full_rec table for storing MFHD records and their corresponding flattened representation; sre currently links to a bib record
  * makes serial.subscription.end_date nullable to represent current subscriptions in a simpler fashion; whereas the intent expressed at http://open-ils.org/dokuwiki/doku.php?id=acq:serials:model had been to have one subscription per year, it might be easier (at least for migrating existing data) to generate a single subscription record with a start_date representing the start of holdings and end_date null to indicate that the subscription is current (still receiving issues)
  * adds serial.issuance.location to give issuances the ability to have a shelving location without having a barcode
  * links the serial.*_summary tables to serial.subscription rather than to asset.call_number; serial.subscription already has a link to asset.call_number, and the existing DDL actually references serial.subscription even though the column name is "call_number"

  * adds IDL for the serials schema (my first major chunk of new IDL, so there are likely some errors here)
  * adds a vestigial OpenILS::Application::Ingest::Serial package for ingesting serial records
  * adds a marc2sre.pl import script for generating sre JSON records, based on the MFHD generated by our system

My current thoughts (such as they are) for a short-term method of supporting serials in Evergreen is that we could maintain raw MFHD records in serial.record_entry, hook up the MARC editor to enable editing the MFHD associated with a given bib record, and ingest/reingest the records to populate the other serial.* tables.
David's MFHD code appears to be getting close to the point that we would be able to hook into it in O:A:I:S to "do the right thing" for generated holdings and generated labels on issuances. Once the ingest code does what it should, it should be relatively easy to teach the OPAC to lookup and display available serial holdings.

There's enough going on here that I would like to start working with the code in the repo, but before committing it I wanted to ask my fellow devs for their thoughts or concerns about the direction this code is headed.

--
Dan Scott
Laurentian University