[282] in ad-lib
Notes on the 949 Expansion Table
daemon@ATHENA.MIT.EDU (Eric Celeste)
Tue Apr 4 16:39:47 1995
Date: Tue, 4 Apr 95 16:38:23 -0400
From: Eric Celeste <efc@wonder.mit.edu>
To: ad-cat@MIT.EDU
Reply-To: efc@MIT.EDU
OK, gang, I've been thinking about this LIOCLN-like table that MR offered us
(for a price). First, we need a name for the beast, so I'm calling it the
"Expansion Table" since it expands 949a codes into a whole bunch of values.
I want to write some of my thinking down where all can see to serve as both
a reality check and a source of questions for Geac.
*** What will the Expansion Table do?
Upon loading records into the Advance database, the loader (UBIX?) will call
a routine that compares the incoming 949a to the codes in the Expansion
Table. If this routine finds a match, then it will use the location,
sublocation, collection, call number prefix, and circ code found in the
Expansion Table when creating the monograph item (852) tag or the serials
summary holdings (866) tag. When there is no call number present in the 949,
the routine will also use the Expansion Table to determine which
bibliographic tag(s) to look at for the call number associated with that
949. If any of the subfields filled in by the Expansion Table are _already_
filled with data in the 949, then the 949 data will override the data from
the Expansion Table.
If no match is found for the code in the 949a, the routine should somehow
report this fact (a daily report?) and store the incoming bib with its
questionable items in the workfile.
[NOTE: This departs from MR's description in his 3/28 message. (1) We need
to create both 852 AND 866 tags, depending on format (or possibly on 949
indicators) and (2) we would not require special treatment of brackets (see
more discussion below.]
*** What might the Expansion Table look like?
MR gave us a sample of what the "front end" might look like in his earlier
e-mail. It will be a lot like other Advance tables... When we type the
keyword from the menu we will get a list of codes and their descriptions...
When we select one of those codes we will get a screen of values associated
with each code. Those values would be: Description, Institution,
Sublocation, Collection, Call Number Prefix, Call Number Precedence,
Circulation Code. MR's message also includes Pieces Suffix and
Classification Code, but I am unsure what these are.
We can devise any coding scheme we need to help us simplify our cataloging
lives. Note that we don't have to develope a code for _every_ combination of
these values, just those common enough to justify the effort. We had over
200 combinations coded in the LIOCLN table, I could easily see thousands
developed for the Expansion Table. That might become a bit painful to
manage.
*** What might the codes look like?
One option would be to take each entry in the sublocation, collection, call
number prefix, and circulation tables and give them briefer codings that
would be combined into Expantion Table codes. Let's just use a small sample
of these tables to devise examples...
* Sublocation
BARKER -> B
DEWEY -> D
LINDGREN -> LIN
* Collection
STACKS -> S
REF -> R
GOVDOCS -> G
* Call Number Prefix
THESES -> T
VIDEO -> V
CDROM -> CDR
* Circulation
GEN1 -> G
NOCIRC -> NO
These vastly simplified tables would still result in 54 Expansion Table
codes, all combiniations of the values above. (Our actual tables would lead
to thousands of codes). For example:
B-R-CDR-NO would represent a Barker CD-ROM on Ref
D-G-V-NO would represent a Dewey Govdoc Video that does not circulate
and so on...
In practice, far fewer codes could serve most of our needs, the old LIOCLN
table is a good guide here. It has only a few hundered values. Most
sublocations could be given a single letter (same as the fourth character of
LIOCLN stamp). We could follow that with a letter to indicate periodical
(P), government document (G), or thesis (T). This would be followed by a
dash and a format code: microfilm (FILM), microfiche (FICHE), audio cassette
(CASSETTE), computer disk (DISK), computer tape (MAGTAPE), motion picture
(FILM), record (RECORD), photograph (PHOTO), slide (SLIDE), videotape
(VIDEO), videodisc (LASER), etc. This would result in far fewer codes much
more like the current LIOCLN, though briefer and without brackets.
For example:
B -> subloc:BARKER, coll:STACKS, circ:GEN1
BP -> subloc:BARKER, coll:JOURNAL, circ:HOURLY1
BP-FICHE -> subloc:BARKER, coll:MFICHE, circ:NOLOAN
DG-FILM -> subloc:DEWEY, coll:STACKS, circ:GEN1, use sudoc call #
HT-FICHE -> subloc:HUMANITIES, coll:MCRFORM, pre:THESES, circ:NOLOAN
Q -> subloc:HUMANITIES, coll:WOMENS, circ:GEN1
and so on...
I know this needs much more discussion and certainly a good bit of
deliberation, maybe we can do that at a meeting near you soon! I'm typed out
on this topic for these two days, so I'll stop here.
*** Questions for MR
(1) Our LIOCLN table dealt with both monograph and serial 949's, can the
Expansion table be made to do the same?
(2) Does the coding scheme we choose for the Expansion Table matter at all
to Geac or affect the programming we are asking Geac to do? For example, if
Geac codes for brackets, can we still use codes without brackets? Can we use
dashes or other punctuation in our code values?
(3) Is there an upper limit to the size of the Expansion Table? Could we
comfortably develop a table with hundreds of codes? Thousands?
(4) When will this Expansion Table routine be called? Will it be used from
UBIX? How about PRISM.TO.ADV or the GeoCat-to-Advance loader?
...Eric
Eric Celeste / MIT Libraries / 14E-210A / 617-253-0633 / efc@mit.edu
