[896] in ad-lib
Revised loader specs from Geac
daemon@ATHENA.MIT.EDU (Eric Celeste)
Wed Jun 21 15:44:41 1995
To: ad-cat@MIT.EDU
Date: Wed, 21 Jun 1995 15:44:31 EDT
From: Eric Celeste <efc@MIT.EDU>
This afternoon I reviewed the loader specs dataed 950620 and faxed by Geac
to Grant this morning. Below are my comments on these specs, which won't
make a whole lot of sense unless you have the Geac document in hand.
Amanda is carrying a copy of the Geac document to ALA for Sarah, and I'll
try to bring a copy along as well. I've already called Beth (the
programmer doing this work at Geac) and shared these comments with her.
She had no problems with any of it and will send a revised spec to Ellen
(Geac Professional Services) who will send the spec to Grant for our
acceptance. This all may happen as soon as this (Wednesday) afternoon. It
might take until tomorrow. My bottom line is that the spec from Beth looks
real good, if you see glaring holes scream loudly and quickly!
...Eric
ADVANCE LOADER SPEC COMMENTS
Responding to Geac's loader spec of 950620 / 21 June 1995
Grant, The Geac spec appears to be acceptable with the following
revisions. ...Eric
I. Matching.
Section I. makes no mention of the 001. As per our loader spec, the 001
(OCLC number) should be mapped to an 035 and it should be the first 035 on
the record (it's position as the first 035 will help us distinguish
between 035's mapped from the 001 and 035's mapped from the 019, which
otherwise would be identical).
Section I.a.2. should specify that each 019 $a should become a separate
035a. In other words, we don't want multiple $a's on a single 035, but
rather want multiple 035's. GMA2 mapped this data in the correct manner.
Section I.c.3.i. should specify an error type of "Multiple matches - 599"
so that we can distinguish between this condition and that of section
I.c.1.iii. This is a minor point.
Section I.c.4. should specify "multiple 599's with both indicators blank".
Many records will have multiple 599's with other indicator values and this
must be allowed.
III. Call numbers.
Section III. has a typo in the first paragraph. I'm assuming that Geac
means "...and creating an 852 field based on...".
Sections III.A., III.B.1.c., and III.B.2.f. all take very literally our
example of "099,090,050" which is not meant to be all-inclusive. The call
number precedence feature must allow us to specify call numbers from other
MARC fields as well. In the one other field commonly used at MIT, 086
Government Document Number, those call numbers will not even be LC style
numbers.
Section III.B.1.b. should note that the 949 $a will never override the
default value in the code table for the 852 $a.
Sections III.B.2.a.-III.B.2.e. should only apply when the call number from
an 050 or 090 is being used. Only the first of multiple 086 $a's should be
used. Multiple 099 $a's should be concatenated together (without adding
spaces) and used as a whole in the 852 $h.
Section III.B.2.f. should specify an error type of "No call number". This
is a minor point that just makes the reports easier to digest.
