Hello,
I will try to be briefer than usual, as I really want to get some initial
reactions before I go to far in trying to think this out. Basically, when I
began working on serials, I kept with the idea that a MFHD record would be
central to both predictions and holdings. Being the opaque and complex format
that it is, this adds some fairly serious complexity and overhead to serials
management (predicting, receiving, claiming, discarding, and displaying). What
we really want is to maintain full compatibility with the MFHD standard without
the overhead of maintaining a full MFHD record. The simplest way to do this is
to keep MFHD field data in some stringified form (where appropriate), but to
associate this data directly with the element it represents. This is precisely
what we have done with the issuance table, as it has fields for storing the
enumeration/chronology statement (863-5) which the issuance represents. We
have also parted out the textual holdings (866-8) to be directly associated
with the appropriate holding library via the distribution table (and friends),
and location and item information are handled by the item and unit tables.
At this point we really need to ask, what's left? The answer: not a whole lot.
Chief among the survivors are the caption and pattern statements (853-5). I
am proposing we get those out as well. We will continue using the MFHD data,
but it will be stored where it is most relevant, not as a central record (which
we could always regenerate for export purposes). We will need at least one new
table, something like:
serial.caption_and_pattern (
id SERIAL PRIMARY KEY,
base INT NOT NULL REFERENCES serial.base (id) ON DELETE
CASCADE DEFERRABLE INITIALLY DEFERRED,
type TEXT NOT NULL CHECK (type IN
('basic','supplement','index')),
active BOOL NOT NULL DEFAULT FALSE,
marc TEXT NOT NULL,
enum_1 TEXT DEFAULT NULL,
enum_2 TEXT DEFAULT NULL,
...
);
The first five columns are essential, but I can see benefits from separate
columns for each level of enumeration and chronology captions as well. I also
propose (as evidenced by column 2) that we create a new root table called
'serial.base' (or something similar). What do we gain by doing these things?
1) In the most recent schema, holdings data is linked to its matching
caption/pattern via subfield 8s in various fields 'hidden' within the marc
column of serial.record_entry. While it is therefore well-defined, it is also
invisible to the DB layer. A separate caption_and_pattern table will allow the
holdings data to reference its caption/pattern data directly.
2) If we proceed (as planned) to create columns in both caption_and_pattern and
serial.issuance to hold the non-repeatable enumeration and chronology fields,
we can reliably query for and display a single issuance or group of issuances
without consulting the MARC at all.
3) We can easily augment places where the MFHD standard is weak. One very
obvious place is its failure to identify whether a pattern should be considered
active or not, a problem this table easily rectifies.
4) The only 'serial' table currently in production use is serial.record_entry.
Rather than altering or repurposing it, we can allow it to hang on as-is for
those libraries (like us, Laurentian, and perhaps others) which have invested
in it (we have around 1,650 of these records in use). Doing so will allow us
to phase in the new system on our own terms.
Well, this is getting longish, so I'm going to stop there and hopefully get the
first reactions I am seeking. Thank you very much for your time and thoughts.
Sincerely,
Dan Wells
--
*********************************************************************************
Daniel Wells, Library Programmer Analyst d...@calvin.edu
Hekman Library at Calvin College
616.526.7133
