[OPEN-ILS-GENERAL] Call numbers in Evergreen

[Dan Scott]

On Tue, 2010-07-27 at 15:33 -0400, Kathy Lussier wrote:
> Hi all,
> 
>  
> 
> The MassLNC consortia have been looking at the way Evergreen handles
> call numbers and had some thoughts for possible enhancements. I wanted
> to share these ideas with the general community to see if there is any
> interest in making these changes. 
> 
>  
> 
> To provide some background, two of our consortia that will be moving
> to Evergreen include libraries using both Dewey and LC classification
> schemes. I have seen previous discussion about creating a sort
> algorithm for LC - http://markmail.org/message/fvbptjffblwvyedu - but
> I wasn’t sure if any development had been done. For our consortia, we
> would need to be able to support Dewey, LC, and the default free-text
> field (what we refer to as “other”) within the same Evergreen
> instance. 
> 
>  
> 
> One approach we were considering is that, when entering a call number,
> staff would need to clearly identify whether the classification scheme
> is Dewey, LC or “other.”  The system would then know which sorting
> algorithm to use, and there would be no mixing of Dewey numbers with
> other homegrown alphanumeric numbers when doing a sort. At the same
> time, we were concerned about adding an extra step to the cataloging
> process where staff would need to change the default classification
> scheme every time they needed to add a DVD or a book of fiction to the
> system. If the call number were tied to the item record, we could
> identify the classification scheme in the item template, but Evergreen
> doesn’t work that way. I don’t know if there are other ways the system
> could determine that the default classification scheme for Library A
> is Dewey for non-fiction books, but “other” for fiction books and all
> DVDs.
> 

Having different default classification schemes for particular subsets
of a collection at a single library is more complex than the direction
we had been thinking. Most of the libraries in our consortium are either
LC or Dewey, and never the twain shall meet. Although... right now my
own library includes a mix of LC for most of our collection, CODOC for
our government documents, and accession numbers for reserve items. So
there's definitely some merit to considering a more complicated scheme;
we would need a config.classification_scheme table to support
per-library default schemes, so perhaps asset.call_number could grow a
"class_scheme" column that points to the pertinent
config.classification_scheme table to override the library default...

LC _almost_ sorts correctly out of the box today, but not quite; you'll
get runs like:

GV1449.5 .S73
GV14.4.C37
GV14.4.K44 1983
GV1450.2.F67

To alleviate that, I have been thinking for a while now (but haven't
done anything as of yet) of adding a Library Setting that would allow
administrators to define a single classification scheme as a default for
a given library. Then the system would generate the appropriate sorting
key for each call number correspondingly.

A Perl module like Library::CallNumber::LC will generate sort keys that
can then be stuffed into an additional column in asset.call_number and
used to properly sort the results. This would be easy to add as a
trigger on the asset.call_number table (find the classification scheme
library setting for the owning_lib and apply the sort key accordingly).

Figuring out how to create sort keys that sort "correctly" across mixed
sets of classification schemes, though - for some reason that seems
hard. Could just be too late for my brain to work properly.

> 
> We also wanted to float the idea of breaking up the call number into
> multiple fields as opposed to putting the entire call number (prefix,
> call number, suffix) into one free-text field. We have many libraries
> that use J as a prefix for children’s materials while others use juv,
> and there are many other areas where the prefixes differ. Pulling
> those prefixes and suffixes into different fields could simplify the
> process of creating reports based on call numbers, sorting by call
> number, and possibly creating spine labels. 
> 

Interesting. In the past we used prefixes on our call numbers to
identify which library holds a given book, but we've done away with them
to avoid messing up call number sorting in the loverly shelf browse. The
idea of having non-sorting prefixes and suffixes is intriguing -
although I wonder if it would make more sense to work out a programmatic
way to tell the spine label editor to generate a given prefix or suffix
when printing a spine label, rather than manually entering that
information into new fields all the time.

> 
> We’re interested in finding out how others in the Evergreen community
> would feel about these changes.