This is an old revision of the document!
Table of Contents
Proposal: Serials - Basic Predicting and Receiving
This proposal is still in progress, please do not edit yet
Summary
Now that MFHD records can be added and are linked to bib records, the next step is to start populating the issuance table in order to predict and receive issues. As issues are received the MFHD record must be updated accordingly. This proposal will focus on fleshing-out the database schema and defining how the MFHD record will hook in.
Details
Schema
Starting with the database schema, here are some notable problems and possible solutions.
- Problem: the current schema provides no means of storing prediction information or reception metadata.
Solution: expand the issuance table to include such data.CREATE TABLE serial.issuance ( id SERIAL PRIMARY KEY, + creator INT NOT NULL DEFAULT 1, + editor INT NOT NULL DEFAULT 1, + create_date TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT now(), + edit_date TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT now(), subscription INT NOT NULL REFERENCES serial.subscription (id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, target_copy BIGINT REFERENCES asset.copy (id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, location BIGINT REFERENCES asset.copy_location(id) DEFERRABLE INITIALLY DEFERRED, binding_unit INT REFERENCES serial.binding_unit (id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, label TEXT NOT NULL, + date_published DATE DEFAULT NULL, + date_expected DATE DEFAULT NULL, + date_received DATE DEFAULT NULL, + date_claimed DATE DEFAULT NULL, + is_expected BOOL NOT NULL DEFAULT TRUE, + is_received BOOL NOT NULL DEFAULT FALSE, + is_claimed BOOL NOT NULL DEFAULT FALSE, + expected_code TEXT DEFAULT NULL, + comment TEXT DEFAULT NULL );
We should also consider removing 'location', as that can be represented in the 'target_copy' and will also be in the proposed 'distribution' table (see below). The 'expected_code' field will be used to store a flattened version of the corresponding 863 field for simpler re-instantiation.
- Problem: Multi-issue subscriptions are not easily accommodated.
Solution: Add another abstraction table called 'distribution' to sit between 'subscription' and the other pieces. It would perform many duties of the current subscription table, leaving subscription to deal with global data.CREATE TABLE serial.subscription ( id SERIAL PRIMARY KEY, - callnumber BIGINT REFERENCES asset.call_number (id) ON DELETE SET NULL DEFERRABLE INITIALLY DEFERRED, uri INT REFERENCES asset.uri (id) ON DELETE SET NULL DEFERRABLE INITIALLY DEFERRED, start_date DATE NOT NULL, end_date DATE -- interpret NULL as current subscription ); CREATE TABLE serial.distribution ( id SERIAL PRIMARY KEY, subscription INT NOT NULL REFERENCES serial.subscription (id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, record_entry BIGINT REFERENCES serial.record_entry (id) ON DELETE SET NULL DEFERRABLE INITIALLY DEFERRED, location BIGINT REFERENCES asset.copy_location(id) DEFERRABLE INITIALLY DEFERRED, call_number BIGINT REFERENCES asset.call_number (id) ON DELETE SET NULL DEFERRABLE INITIALLY DEFERRED );
Subsequent tables (binding_unit, issuance, *_summary) will then link to 'distribution' rather than 'subscription'. The distribution table will also provide the linking point to the 'record_entry' (MFHD) table (and exist in a 1-to-1 relation with 'record_entry').
- Problem: binding unit should function as an asset in some way.
Solution: we could add a link from the 'binding_unit' table to the copy table, or we could possibly set each 'issuance' copy to the same copy id (a bound-with type implementation). The complete ramifications of each approach are still undetermined.
MFHD Choices
The MFHD standard allows for a fair amount of flexibility in some areas. An eventual goal will be to provide configuration switches to meet the preferences of individual libraries, but the initial implementation will focus on a single working model. A few examples are:
Level of compression
- No compression: When not using compression, MFHD records will have a separate field 863 for every issue. This is generally untenable for anything but the simplest cases (or cases where the serial is unpredictable), and there are no plans to support it at this time.
- Partial compression: partially compressed holdings will normally have a separate 863 for each bound volume. This physical level of holding information is more or less duplicated in the 'binding_unit' table and unnecessary for expressing holdings from a coverage perspective. As some libraries wish to express this physical-item/holding relationship in their MFHD records, this option is still planned for future development.
- Full compression (initial plan): fully compressed holdings express full coverage information in the least possible space. Links to physical items are not supported. The initial receiving code will focus on fully compressed holdings as they meet the primary purpose of holdings information (coverage) with the least effort.
Automatic vs. manual editing
- Fully automatic: the holdings fields are fully managed by the serials interface. This approach may seem ideal, but it restricts manual editing by knowledgeable librarians and depends upon a fully implemented and flexible model. It also depends on accommodating historical information (pre-Evergreen holdings) in some way.
- Fully manual: manually editing holdings with no automation should be possible, but only as a last resort.
- Partially automatic (initial plan): partial automation will allow a mixture of auto-generated fields and manually edited fields. There is no direct expression of this in the standard, so we will use 'internal note' subfield to tag fields which are under automated control (setting the note to 'EGAUTO' or something similar). Any field lacking the this tag will remain untouched by the automation code.