This proposal is still in progress, please do not edit yet

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.

Starting with the database schema, here are some notable problems and possible solutions.

1. 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_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'. The 'expected_code' field will be used to store a flattened version of the corresponding 863 field for simpler re-instantiation.

2. 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,
   	        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').

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:

1. 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.
2. 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.
3. 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.

1. 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.
2. Fully manual: manually editing holdings with no automation should be possible, but only as a last resort.
3. 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.