[356] in ad-lib
Summary Items for Serials
daemon@ATHENA.MIT.EDU (Eric Celeste)
Tue Apr 18 16:14:54 1995
Date: Tue, 18 Apr 95 16:14:44 -0400
From: Eric Celeste <efc@wonder.mit.edu>
To: ad-cat@MIT.EDU
Cc: sercat@MIT.EDU
Reply-To: efc@MIT.EDU
OK, Where are we with serials holdings? It's been a few weeks since I
realized that maintaining holdings in the 866 would not work well for us and
I've been thinking out loud with a number of people since then. I am
starting to settle into a new plan, so I thought I'd share it here to see
what you all think of it and make sure everyone has a chance to scream
bloody murder.
A small glossary up front may help folks who have not been immersed in this
issue...
930: the MARC field where our summary holdings are stored in GLIS.
866: the MARC field where our summary holdings are stored in GMA1.
ITEM or PIECE RECORD: a record linked to a bib record or copy set which
stores information about an instance of that bib's title, including
location, call number, and notes. Kinda like the circ records in GLIS.
COPY SET: a record linked to a bib record which stores information about
a set of holdings of that title. Item records and checkin records are
linked to copy sets. Kinda like the current kardex cards.
First, why is the 866 not sufficient? At a long-ago TSF meeting I described
how useful it would be to have an 866 with authoritative summary holdings
leaving the copy set to Serials Receipts for maintenance. Here are the
shortcomings of that plan that emerged over time:
(1) Advance does not index call numbers from the 866, this made serial
call numbers unsearchable. This could (?) be solved with expensive
programming, but it would not be pretty.
(2) Locations in the 866 are useless to the rest of Advance. For example,
searches qualified by "DEWEY" would not actually retrieve Dewey
serials.
(3) Any maintenance to an 866 must be done in the cataloging module.
Since we cannot control editing access to MARC records at the tag
level, anyone with the authority to change 866 tags could change
anything in any MARC record. 866 tags could also not be changed
through general Advance tools such as mass holdings update.
(4) Other less important reasons... they are pretty ugly in the OPAC
display... they could be a pain to build from the Expansion Table...
they are overwirtten every time we transfer an edited bib from
OCLC...
and I'm sure I've left out some other drawbacks.
According to MR (and confirmed by some testing), call number are only
indexed from item records in Advance. In other words, for a call number to
be indexed an item with that call number must be present in the database.
Locations are drawn from both item and copy set records. Item records can be
maintained from CAT:CEHI and copy sets from SER:HLDM, so neither needs
acceess to MARC editing.
A modest proposal: Ask that GMA2 migrate 930 data into both 866 tags and
item records. The 866 would serve as a backup, we know its ugly, but we know
it is doable. I would hope we never use or display the 866 data to the
public. The item records would _not_ include barcodes, but they would
include our summary holding (930j) and note (930i) information in the
preservation note area of the item record. I think of these as summary
items. Remove 866 tags from public display and let the public learn of
summary holdings through these summary items.
Advantages: call numbers are searchable, locations are usable by the system,
summary holdings show up in the part of the screen users look at for other
holdings information, serials cataloging could use 966's just like
monographs cataloging with no special treatment needed in the Expansion
Table software, the sky would be a little bluer.
Short term issues: Adding "No call #" to the call number index could make
the index choke... perhaps "No call #", when encountered, should be moved to
the accession number instead, so that it still shows up as a note to the
patron. The Expansion Table will also have to do the right thing with a call
number "x". Monographs intends (I think) to use the item record's
preservation note as a place to put public notes, if so, we should delimit
the text in the display with a generic string (such as " / ") instead of a
specialized string (like "Note:").
Medium term issue: Upon the addition of any copy set to a record, all the
item records not linked to a copy set become invisible to the user. Each
summary item really represents a "copy set" anyway, so the right thing to do
would be to replace all summary items with copy sets once any copy set needs
to be created, but this is a _chore_ that will have to be done. It's recon,
of a sort.
Long term issue: Note that the summary items would be left on the record
even after the copy set is created since they will still be required to make
the call number searchable. Should they be linked to their equivavlent copy
sets? Should they be maintained in some way? Should they be stripped of
their summary holdings (to avoid confusion with the copy sets' own summary
holdings)? The long term fate of summary items still needs thought.
Comments?
...Eric
