Last Updated: August 10, 2005 by Beth Siers

Known Problems for Cataloging

Indexing:

  • With the upgrade to 16, ExL dramatically changed the way browse indexes are built. It's now a three step process, rather than one, and we're still working out the kinks in what that means for table setup. The biggest known glitch so far is the handling of subfields. It's leaving and extra space where the subfeild was, and thus things with subfield delimeters are filing before things without them. To see this try browsing the title index at: united arab emirates
  • For very long records, Aleph could not index all keywords, so those records were not be retrieved under some of the words in the record. Browse and direct indexing did not seem to be affected. The problem was reported to ExLibris, and now cannot be reproduced. If you find another example of this, please let me know, as we're now assuming it is no longer a problem.
  • Only the first 69 characters of a heading are in the index, so while the headings are sorted beyond that, you can only get dropped into a browse index based on the first 69 characters.
  • Searching of things indexed as a space is not working properly and ExLibris is working on a solution. The best way around this bug is to enter the space directly into your search for the following characters: / : ;
    Parens and dash can be included in the search, even though they are also indexed as a space.
  • Searching of OCLC# requires the leading zeros. We've learned that this can be fixed in version 16, but no testing has been done yet.
  • Call Number browsing is much improved, but there are still a small number of things to be aware of when searching.
            -There are pockets in the G schedule where it is LC practice to NOT include a period before a subject related cutter. These are not being recognized by ExLibris's routine as cutters, and thus filing out of order. For example, G5754.C25A3 1588.B7 1971 is incorrectly filing before G5754.C2A3 1585.B7 1974.
            -Half class call numbers file after ones with a class number, for example: QA.A167 files after QA1081.U54.
            -Class together series numbering is not filing correctly. For example: TK7855.M41.L741 no.919 files before TK7855.M41.L741 no.92.
  • Items on serials-within-classed-together-series may not appear in the call number browse index. We have identified a way to force them to, but not a way to identify all those items affected. If you find one of these, please send email to me and I'll have it fixed, and we're still looking for a way to identify all those affected.
  • For Bound-With items, linked together in Aleph, the results list in a call number browse is a bit misleading. For example, there are six items linked to call number QA47.T759 no.5-10, and entries for each volume individually. A browse search of the call number direct index, however, displays the six items attached to no.5, rather than to no.5-10.
  • When there is a see reference which points to multiple authorized headings, only one of the authorized heading appears in the browse list of headings for the see reference. This problem is one of the enhancement requests sent to ExLibris, and was voted in to be an enhancement during the 2001 process. We should see this in version 18, we hope.
  • For Bound-Withs and Analytics (ITM and ANA type LKR fields), if an update is made to the master HOL record, only the master bib record will be updated in the indexes. The children will reflect the old call number information. To force indexing, simply file all child records again. If records are missed, they will be automatically fixed with any future re-indexing. This problem has been reported to ExL and they sent it for programming (ISRPRB 36893).
  • When a heading used in a bib record is only a partial match to an authority record, the cross references are not automatically included into the indexes. You can force them to be added by changing the bib heading temporarily to match exactly the authority heading, letting it index fully, and then returning the bib heading to its correct form.

    Migration Related Problems:

  • Item statuses (formerly Circ Codes) are not correct for journal analytic records.

    Diacritics:

  • We have made great strides in the display of our diacritics and special characters. There's a group working on the display in the web catalog made up of Nicole Hennig and Pam Nicholas. If you're still having problems displaying diacritics in the GUI, getting a font with the expanded Unicode set, like Ariel Unicode MS fixes the problem. Library staff can find this font under their Network Neighborhood in the \\Turnpike\E\LTE\Users\Beth\Fonts folder.
  • Some grabbed one character/space past them. This is a problem with super and subscripts and Greek letters. e.g. aHydroxy instead of a Hydroxy. We have mostly completed reports of these from migration, and from early loading. New records loaded are fine.
  • Ligatures were broken during migration. Those that migrated appear as only half a ligature. We have a list of those affected and a project has been undertaken to fix them. Chorallary to the ligature problem: new records loaded before patch 5 have both pieces of the ligature, but in the wrong place. This causes them not to match with identical headings that migrated with the above problem. Current loading of ligatures is correct, so until we finish with the reports, there could be 3 versions. Also the reccomendded unicod value for the ligatures has recently been changed. We're likely to convert all three versions to the newly assigned character, and hopefully they will merge in the process.
  • Double combining diacritics (where two symbols modify one character) were problematic to migrate, there will be cleanup needed to make these display correctly.
  • Many, many diacritics were broken before migration. At one point GEAC could not handle super and subscripts, polish l's and several other diacritics. Most have now been fixed manually. Some super and subscript numbers were changed to the number directly, and there is no way now to identify all instances of these.
  • Records being loaded with non-roman scripts included (e.g. Chinese) lost data during the loads prior to patch 5. Punctuation within a subfield seems to set off the missing data. So while some Chinese characters are making it into records, the headings are not complete. This problem was possibly solved with patch 5, but there has not been sufficent testing to confirm.

    GUI Displays:

  • Long contents notes are being truncated for all GUI OPAC views, Web displays include the tag limit of 2000 characters. However some displays add html tagging and thus truncate the dispalays of records close to the 2000 character limit.

    Functionality of Aleph:

  • Even though cataloger is stored in the item record, there is no way to display them from the items tab, other than wehre it appears in item history.
  • System has no check on barcode entry, and allows incomplete or incorrect barcode wands.
  • Occasionally, and without provocation, the keyboard equivalents no longer work, and you must use the menus to invoke commands. Restarting the module seems to clear this up, but it also can clear up on its own for no apparent reason. This is still happening in v.16.
  • The indexing set off during the loader process is given the lowest priority in the queue. If any batch job is running while the load happens, none of the new records will get indexed until the batch job is finished.
  • During the step of the load that creates items and holdings, and error message appears about the item on records where the 949 is speicfying holdings only.
  • When you create a HOL starting from the bib record, the leader defaults given are NOT coming from the table we can set them in. The problem has been reported to ExLibris by other libraries.
  • With no discernable cause, some HOL records created during the load will have a different Sub-Library than the 949 details. It happens on records with multiple 949's, but no other pattern can be identified.

    Questions about these can be directed to siers@mit.edu