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

[Mike Rylander]

On Thu, May 20, 2010 at 11:49 AM, Scott McKellar <mck9 at swbell.net> wrote:
> A few days ago I posted a proposed serial schema in the form of an upgrade script.  That post focussed on the details of columns and clauses.  This post is an attempt to provide a conceptual description of how the tables work.
>
> The following description is *not* authoritative -- it is just my own interpretation.  The design is mostly the brainchild of Dan Wells and Mike Rylander.  I hope they will provide any appropriate corrections, clarifications, and amplifications.
>
> You may find the following diagram helpful:
>
> https://docs.google.com/drawings/view?id=196Cyl9CAIzZ33cOVt0AphvUSbAwc9kfRGRB5Nz-5tTI&hl=en
>
> -------------------
>
> 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.

> -------------
>
> Serial.distribution
>
> For a given subscription, the serial.distribution table defines where the copies may go.  A row says that a given org unit may receive copies, and (via links to asset.copy_template) defines various aspects of how the copies will be treated: where they are shelved, whether they circulate, and so forth.
>
> For example, a given org unit might get two copies of Consumer Reports: one goes on the magazine rack and the other goes in the reference room.  Two rows in serial.distribution would define these two different treatments.
>
> Note that serial.distribution does *not* define the number of copies.  If a branch gets two copies of Newsweek every week and puts them both on the magazine rack, and otherwise treats them identically, a single row in serial.distribution can cover both of them.  It is even possible for a distribution to receive zero copies.
>
> Hence a row in serial.distribution defines a bucket where you can put magazines.  How many magazines you put in the bucket, if any, is defined by serial.stream (below).
>

Check.

> ------------------
>
> Serial.stream
>
> A row in serial.stream represents a succession of physical copies of a magazine.  If the system gets five copies of Newsweek every week, there will be five rows for Newsweek in serial.stream.  Each of the five rows will be linked to a row in serial.distribution, defining where it goes and how it is to be treated.  Typically, but not necessarily, each of the five streams will be linked to a different distribution.
>

Check.

> --------------------
>
> Serial.routing_list_user
>
> Copies from a given stream may be put on a routing list, named in the routing_label column of serial.stream.  The serial.routing_list_user table defines who is on the routing list, and in what order.  A recipient may be either a user (defined by a link to actor.usr) or, for example, a department, identified by an arbitrary text column.
>

Check.

> ---------------------
>
> Serial.issuance
>
> Serial.issuance defines publication schedules for the magazines to which we subscribe.  A row represents the fact that an issue of a given magazine (identified by a link to serial.subscription) is published on such-and-such date.  It might, for example, represent the August 2011 issue of Scientific American.
>
> If there are special editions, or if the publication schedule changes, staff may adjust serial.issuance accordingly.
>
> Since an issuance is tied to a subscription, it may apply to multiple copies.  Since there may be multiple subscriptions to the same magazine,
> there may be some duplication in serial.issuance.
>

There will be a lot of duplication. Once per subscription, in fact, so
in a consortial environment there will be a lot.

We can consider collapsing this so that it's an
application-constrained, MFHD-unique set of publishing events, and
that would provide some benefits, but AFAICT that would complicate the
issuance projection logic significantly ... thoughts, anyone?

> ------------------
>
> Serial.item
>
> Finally, we get to the magazines themselves, not just various aggregations of magazines.
>
> A row in serial.item represents a copy of one issue of a magazine -- a physical copy, unless it's an electronic resource.  It is linked both to serial.stream and to serial.issuance, and thereby linked indirectly to serial.subscription by two different paths.  Both paths had better lead to the same subscription, or else nothing would make sense.
>
> Typically we will create item rows in advance, based on the expected publication schedule in serial.issuance, and check them off as we receive them.  That way we can notice whether they arrive on time.
>
> Some magazines are more predictable than others.  Newsweek comes out like clockwork, but something like the Chatham County Literary Review is likely to be a bit irregular. Accordingly in some cases we won't try to predict items long in advance.
>

And this non-prediction is not controlled at this point.  However,
adding a "volatility" flag to the subscription (or is there a way to
identify, directly, irregular serials via MFHD data?) would be simple
enough if warranted.  Dan (Wells), what does your four-month-test show
in that regard?

> An item may have multiple notes linked to it in serial.item_note.
>
> ------------------
>
> Serial.unit
>
> In some cases, copies of a magazine are shelved (and maybe circulated) individually.  In other cases, a library will collect multiple copies of a magazine together in a binder and shelve them (and maybe circulate them) together as a unit.  In still other cases, the copies will be shelved individually at first, and collected into binders after a few months.
>
> The serial.unit table represents the units of shelving and circulation.  Since it inherits from asset.copy, it enjoys all the rights and privileges appertaining thereunto.
>
> If an item represents an electronic resource of some kind, then it isn't shelved or circulated as such, and doesn't link to serial.unit at all.  However if it is a physical copy, then it links to a row in serial.unit.  If it is shelved individually, then it is the only item linked to that unit.  If it is bound and shelved with other copies, then multiple items will link to the same unit.
>
> Normally a unit will include issues of the same magazine, but nothing in the schema enforces such a restriction.  It would be possible to bind a copy of Popular Mechanics together with copies of Popular Science, Popular Photography, and People, and represent the resulting mish-mash in the serial.unit table.
>
> ---------------------
>
> There are a number of areas that I haven't covered, either because I didn't want to get bogged down in details or because I don't understand them myself.  However I hope this brief account can provide a framework for further discussion.
>

Thanks, Scott!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com