[54] in ad-lib
Re: Cataloging ISSUEs
daemon@ATHENA.MIT.EDU (Sarah Mitchell)
Sat Feb 25 13:56:41 1995
To: efc@MIT.EDU (Eric Celeste )
Cc: ad-cat@MIT.EDU
In-Reply-To: Your message of "Fri, 24 Feb 1995 17:31:40."
<9502242231.AA20179@MIT.EDU>
Date: Sat, 25 Feb 1995 13:56:26 EST
From: Sarah Mitchell <smitchel@MIT.EDU>
I have a couple of questions/changes on the items below. I'd restate the
accession number problem to "Geac has mapped the accession numbers that
appear on some of our records in 966 $a into the Advance call number
field. Accession numbers should be stripped from our Geac records in
the 2nd GMA. Is it possible to omit them from indexing before the 2nd
GMA?"
Is your 'strip the leader from the OCLC no.' just a variation on the
earlier issue in this list about the 'ocl7 and ocm prefixes'?
OCLC DELHLD command: I understand that this is the Prism way of doing
the old CANCEL UPDATE command to remove the user location symbol from the OCLC
record. Yes? If yes, then, it may help Geac to know that the CANCEL
transaction type code is X'03' in offset 22 in the OCLC leader.
>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)
>
>
