Reindexing Project

This page lists the changes the Reindexing subcommittee is proposing.


1) Remove 074 from ISN index

  • It is very common for many government documents to have the same 074, so this is not a unique identifier.  A number that is not unique should not be in the ISN field.  This results in many unhelpful hits in the Headings Report duplicate checker.  Removing the 074 from the ISN index would unclutter Headings Reports making it easier to use.
  • This will still be indexed as a keyword, so it should still be searchable.

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.



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 will always be 7 or 10 digits, but never 8.  Email addresses will not be mixed because they will always have an @ symbol.

Last updated on 2/15/2018