[OPEN-ILS-DEV] ***SPAM*** Re: Serials: conceptual description of schema

[Scott McKellar]

--- On Fri, 5/21/10, Mike Rylander <mrylander at gmail.com> wrote:

> From: Mike Rylander <mrylander at gmail.com>
> Subject: [OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Serials: conceptual description of schema

<snip>

> > Serial.record_entry.
> >
> > Serials start with serial.record_entry.  Each row
> represents a subscription to a serial publication for a
> particular time period.  The identity of the publication --
> e.g. Popular Mechanics rather than Sports Illustrated -- is
> defined via a link to serial.record_entry.
> >
> > (My examples involve familiar magazines because that's
> my main mental image of a serial publication.  However the
> same principles apply to academic journals and other
> recurring publications like the Annual Review of
> Neurobiology.)
> >
> > A given subscription may involve entail multiple
> copies of each issue -- e.g. five copies of Newsweek every
> week -- as long as the same start and end dates apply to all
> of them.  Conversely there may be multiple subscriptions to
> the same magazine, either because the start and end dates
> are different or for administrative reasons (e.g. they might
> be funded from different sources).
> >
> 
> I think there's a little conflation here.  The
> serial.record_entry
> table contains the MFHD (the information we need to predict
> receipt,
> and other stuff like local information -- thus the ability
> to define
> more than one per bib record) and a pointer to the
> bibliographic data
> for the serial, but doesn't represent a subscription. 
> That's handled
> by the serial.subscription table, which provides the
> calendar-time
> bookends (and ACQ entry point) for a series of issuances
> (publishing
> events) that have been purchased at some point as a group,
> like the
> 2010 subscription to Scientific American, or, for
> migration-type
> historical data, those issuances held at the time of
> migration.

<snip>

I tried to say as little as I could about serial.record_entry, because
that's one of the pieces that I don't really understand.  My point was 
that if you want to know what magazine you're subscribing to, you can't 
tell by looking at serial.subscription; you have to look at the linked row 
in serial.record_entry (and maybe biblio.record_entry).

Agreed, a row in serial.record_entry doesn't represent a subscription,
and I didn't mean to suggest that it did.

If the MARC record in serial.record_entry is necessarily an MFHD record,
wouldn't it make sense to name that column "mfhd" instead of "marc"?  Or
maybe "marc_mfhd", or "mfhd_marc".  One of the things I was puzzling over
was that serial.record_entry and biblio.record_entry both had columns
named "marc", and it wasn't obvious why we needed two of them.

Scott McKellar