[OPEN-ILS-DEV] ***SPAM*** Re: Serials Schema Proposal - Further De-emphasis of MARC as Record Format

[Scott McKellar]

--- On Mon, 5/24/10, Dan Wells <dbw2 at calvin.edu> wrote:

> From: Dan Wells <dbw2 at calvin.edu>

<snip: about further dismembering MFHD record>
 
> 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?

I'm all for de-emphasizing MARC.  Parse that sucker once and never
look at it again.

Questions:

1. What does serial.base look like?  For example, will it link to
biblio.record_entry?

2. Using last week's proposed schema as a baseline, how will the new
tables relate to the new ones?   E.g. will serial.subscription link
to serial.base?

3. Will serial.subscription continue to link to serial.record_entry?
I'm guessing that it won't, since you suggest that we retain
serial.record_entry only as a transitional measure for the few
libraries that already use it.

4. Does serial.caption_and_pattern hold an MFHD record in the marc
column?  If so, is there reason not to call that column "mfhd"?

5. Can we come up with a better name than "serial.base"?  It's too
vague.  It could represent sodium hydroxide, the std::basic_string
class, or Wright-Patterson Air Force Base.  Maybe "serial.periodical"?

<snip>

Scott McKellar