[OPEN-ILS-DEV] ***SPAM*** Re: ***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:

> >>> On 5/24/2010 at 12:25 PM, Scott McKellar
> <mck9 at swbell.net>

<snip>

> 1-3.  Sorry for not being more clear, but I think
> serial.base (or whatever it is called) will be a direct
> replacement for serial.record_entry everywhere it is used in
> the new schema.  So for starters it will have all the
> fields in record_entry minus 'marc'.  We might consider
> going without the 'edit' related fields as well, since there
> won't be much to edit there anymore.

I believe Mike Rylander has proposed leaving serial.record_entry in
place, to serve the same role as your serial.base.  The new
serial.caption_and_pattern table would then be a child of
serial.record_entry.  We might want to make the marc column nullable
in serial.record_entry.

As I understand it, the marc in serial.caption_and_pattern would *not*
be a copy of the marc in serial.record_entry, but a subset of it, or
somehow derived from a subset of it.  Is that right?

Your proposed serial.caption_and_pattern table contains columns named
enum_1, enum_2, and apparently (judging from the ellipsis) a series of
enum_[0-9]* columns.  On its face, that doesn't look very normalized to
me.  Is there a firm, well behaved limit on the number of enum columns?
Is that a reflection of how MFHD records work (of which I am supremely
ignorant)?  Or would it make sense to add a child table to hold the
enums?

The name "caption_and_pattern" bothers me a bit too -- not because the
name itself matters much, but because it suggests, or induces, a bit of
muddlement.  Does a row in this table contain a caption *and* a pattern?
Or maybe one or the other?  Or maybe both?  Or neither?  How do we store
a caption differently from a pattern -- in different enums?

Maybe a different table name is in order, e.g. record_entry_detail.

<snip>

> > 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"?
> > 
> 
> 5.  I agree that serial.base seems too generic. 
> Honestly it should probably be called 'serial.serial', as
> some would argue that the term 'periodical' doesn't
> technically include newspapers (and probably a few other
> minor things).  Again, however, I am willing to be more
> pragmatic than technical if people are opposed to a
> 'serial.serial' table.

"Serial.serial" does have a certain alliterative appeal -- like "Sirhan
Sirhan", or "Boutros Boutros-Ghali."

We could also consider creating a whole new "ser" schema, with a
"ser.serial" table.  Anybody using the old "serial" schema could keep
it around without interference until they're ready to blow it away, or
forever if they want.

Scott McKellar