[50] in ad-lib
Cataloging ISSUEs
daemon@ATHENA.MIT.EDU (Eric Celeste )
Fri Feb 24 17:32:08 1995
To: gyoung@MIT.EDU
Cc: ad-cat@MIT.EDU, rschmidt@MIT.EDU, rchall@MIT.EDU, steps@MIT.EDU,
hkennett@MIT.EDU
Date: Fri, 24 Feb 95 17:31:40
From: efc@MIT.EDU (Eric Celeste )
Grant,
Below is a summary of issues that we have identified in the Cataloging
Implementation Team. This will, I'm sure, be an ever expanding list.
I'm sending it now so you have a chance to incorporate it into your
material for your meeting with MR.
Cataloging ISSUEs to date: 950224
*** Series Numbers [wp]
Series are inaccessible by number because the 4xx and 8xx $v subfields
are not being indexed, presumably because of authority file
considerations. This is a concern to public service librarians, who
are frequently presented with citations like "Lecture notes in
mathematics no. 1081."
One possible solution would be to index 4xx and 8xx $v into the Note
index, so a search W=lecture notes mathematics 1081 (or the finer
search SEW=lecture notes mathematics AND W=1081, or other variants)
would isolate the desired record. PSU's (and patrons?) would have to
be made aware of this method of access.
*** Accession numbers [sgm]
Accession numbers showing up in call numbers. [Was cleaned up in
GMA1.]
*** 599 Label [ss]
In record display (non-MARC), all 599s are showing up with the label
"thesis supervisor:" (for instance, Thesis supervisor = GRSN 60544).
It seems to be ignoring the indicator values. 599 with both
indicators blank = GRSN. 599 with indicators zero zero = thesis
supervisor. (This may simply be a change we can make ourselves.)
*** EBIB Records [sgm]
These did not come across in GMA1. [Michel Ridgeway reports that the
EBIB records have been retrievedand put in the workfile. sgm950220]
*** ocl7 prefix on OCLC control numbers [sgm]
MIT OCLC tape records produced prior to June 28, 1981, carry the
control number identifier 'ocl7' in field 001, bytes 0-3. All records
produced June 28, 1981 and after have the identifier 'ocm' in field
001, bytes 0-2. In order that the Geac indexing and matching programs
perform properly, the 7 (field 001, offset 3) should be converted to a
0 (zero). In addition, the Geac loader and indexing software should
disregard OCLC designators 'ocm' and 'ocl0' in its indexing and
matching programs.
These instructions were part of our original conversion specifications
for the Geac 8000 and should be carried forward into the Geac Advance
system.
*** b.index: 7xx $4; 6xx $w [sgm]
BINDEX:The $4 (Relator code) in the 7xx fields and the $w (Heading
verification code) in the 6xx field were indexed in the 1st GMA.
These subfields should NOT be indexed in the final GMA.
*** Multivolume holdings [sgm]
In looking over a few of the multivolume set records, Ray and I
discovered that the multivolume hierarchies are getting truncated in
the holdings display. [SGM called MR to find out why this was
happening and after a brief investigation he immediately wrote up a
problem report for the Geac programmer, David Alexander.]
*** Barcodes [sdb]
According to my notes, you can search a barcode by scanning it in in
the opac but not through cataloging. We need to be able to scan a
barcode in through the cataloging module.
*** 245 "authorities" [sdb]
When I retrieve a bib record to work on, for each tag, info displays
at the bottom of the screen. One of the categories of information is
"Authority control number." For headings under authority control, its
ACN displays here. For other fields, like 300, 260, etc., it's just
blank.
BUT for the 245, an authority control number is displayed!
245 is NOT, of course, subject to authority control, so it should be
balnk. The number that displays is bogus; I tried searching on it in
the Authority module and it says "invalid control number." Why, then,
does it even display? Get rid of it!
*** ISBN/ISSN index broken [efc]
Check it out! ISSN/ISBN searches don't work on Advance! Has anyone
retrieved a record using one of these indexes?
The problem appears to be that the index was built with bogus local
control numbers. Indexes work by linking a given search key (like,
say, ISBN) with the appropriate record numbers (like, say, the record
that represents a title with that ISBN). So, if bib #10388977 is
"Ender's game" and has ISBN 0312932081, then an "I=0312932081" search
should pull up "Ender's game".
Not in our first GMA! The search "I=0312932081" instead tries to pull
up bib #388977, which does not exist. In other words, every ISBN/ISSN
search pulls up a blank screen. It looks to me like the index was
built without the leading "10" that belongs on _every_ local control
number in the Advance system.
*** strip leader info from OCLC control numbers [efc]
Our OCLC numbers on Advance include the leader info from GLIS. This
should be stripped off the OCLC number as it is migrated.
*** how does the DELH command on OCLC affect Advance? [efc]
We currently delete records from GLIS by issuing a DELH command on
OCLC. Will we be able to do the same thing in Advance? How does an
OCLC hex code for deletion affect the Advance database?
*** THE END (for now)
