Skip to main content
ExLibris
  • Subscribe by RSS
  • ExLibris Dev

    "LC" call numbers with alphabetic class "numbers"

     

    • Product: Aleph
    • Product Version: 20, 21, 22, 23
    • Relevant for Installation Type: Dedicated-Direct, Direct, Local, Total Care

     

    Description: 
    The “22” section of the ./xxx01/tab/tab_filing has the following: 
    !* LC Call Numbers 
    22 del_subfield 
    22 lc_call_no 

    Two classification systems have 852 first indicator "8": the CalDoc classification system, used for California government documents; and a classification system developed in-house for use with a collection of haiku materials. An example of a CalDoc call number is F377.C35, and an example of a haiku call number is "HAIKU I14id 1990". 
    For the CalDoc call numbers, Aleph treats the number before the decimal point as a whole number, and the number in the cutter after the decimal point, as a decimal number. For the HAIKU call numbers, Aleph treats the number in the cutter after the word "HAIKU" as a whole number; it should be treated as a decimal. 
    Why is the system sorting the CalDoc call numbers correctly, but not the haiku numbers? 

    Resolution: 
    "HAIKU" is not a legitimate classification number. (An LC classification number consists of 1-3 capital letters followed by a number from 1 - 9999.) The Aleph lc_call_no routine looks for the first number in the call number, assumes it's the classification number, and treats it as a whole number. 

    To address this: 
    * change the second indicator for the HAIKU call numbers from "8" to something else 
    * create a separate index for these HAIKU call numbers 
    * in the tab_filing entry for this index omit "lc_call_no".
     
    Additional Info
     
    • Article last edited: 02-Mar-2016
    • Was this article helpful?
    //doorbell.io feedback widged