Reindexing Project

This page lists the changes the Reindexing subcommittee is proposing.

BIB RECORD CHANGES

1) Change 690 and 691 to field group tag v, while keeping them in the subject index.

  • We have realized that field group tag v has the property that fields with that tag will move to different MARC records with attached records when you move the attached records.
  • This would be a useful property for local fields like 590, 690 and 691, but when we change a 690 or 691, that removes it from the subject index.
  • We would like to be able to put these in the v FGT, but keep them in the subject index.
  • We would like the label on FGT v changed to "LOCAL INFORMATION"

2) Move 019 from ISN index to BIB UTIL index

  • The 019 is a field for old bib utility number numbers.  Both OCLC and SkyRiver use this field to store their old record numbers when they merge records. 
  • Currently when we download a new version of an OCLC record with a new 001 field, Sierra will not recognize that there is an old version of the record with the same number in the 019. This both creates a duplicate, and leaves an outdated record in the system. Putting the 019 in the BIB UTIL index would make the new record overlay the old one preventing a duplicate.
  • Currently the 019 is indexed in such a way that only the first 019|a gets into the index. The 019 often has many more |a. They should all be put into the BIB UTIL index.
  • Putting the 019 into the BIB UTIL index will also make duplicates between the 001 and 019 appear in Headings Reports.
  • A danger of this is that it becomes possible to overlay a new version of a record with an old one. That would only happen if someone loaded an old version of a record, perhaps supplied by a vendor. However, the vendor loader [S], currently matches on the ISN index, so this is not likely to be a problem.  We should make sure that any loaders that will load records from sources other than OCLC or SkyRiver will match on something other than this combined BIB UTIL index.
  • The Z39.50 loader does match on the BIB UTIL field, so it could make this error, however it is very rarely used.

3) Create Second ISBN index.

  • Currently we have a problem that records have ISBNs for many different versions of things: paper, audio, ebook etc. This means that it is possible for things to overlay on the ISBN of the wrong format creating a bad record in the system.
  • People want to be able to search on all ISBNs in Classic Catalog regardless of format.
  • ISBNs for different formats should be put into 020|z.
  • We propose to create two separate, but overlapping ISBN indexes: ISN(a) and ISN(az).  [Maybe called ISN-1 and ISN-2 or something else?]
  • ISN(a) would only include the correct ISBN(s) for the item(s) described in 020|a fields.  ISN(a) would be used as the match point for record loading.  That way the ISBNs for other formats would not be matches, as long as they are correctly put into 020|z. 
  • ISN(az) would include all 020 subfields.  It would be the searchable index in Classic Catalog, so all formats can be searched.  Each instance of Classic Catalog could be set to search either or both of these.
  • Pika's indexing is entirely separate, so none of this should matter to Pika.

4) Remove |0 and |1 from all indexes

  • The |0 was added into most of our records by the Marcive authority record overhaul process.  While we hope it will someday be useful for linked data in Pika, at this time it creates problems in Classic Catalog. 
  • For one thing, they appear on hit lists, where they are confusing and ugly. 
  • Also, if one record has the |0 and another, with the same heading does not, then the index creates two separate hits on the subject browse.
  • We don't have any |1 data yet, but we anticipate we they will appear at some point.

 

PATRON RECORD CHANGES

1) Create single index for patron birth dates, telephone numbers and email addresses.

  • Some libraries would like the ability to search for patrons by their birth date, phone number or email.
  • These should all be able to live in the same index because birth dates will always be 8 digits and phone numbers should always be 7 or 10 digits, but never 8.  Email addresses will not be mixed because they will always have an @ symbol.
  • The fixed birth date field cannot be indexed.
  • We could index the variable birth date field.
  • The plan now is to use Scheduler to move the information from the fixed birth date field to the variable birth date field every night for Garfield's patrons.

Last updated on 4/09/2018