[OPEN-ILS-GENERAL] Call numbers in Evergreen

[Kathy Lussier]

> 
> 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

[KL] We don't have libraries that mix LC and DDC either, but do have many
that will mix DDC with other alphanumeric schemes or LC with alphanumeric
schemes. We were also considering a sorting algorithm for sudocs since we
have a couple of libraries with government documents, but it isn't as high
of a priority for us.

> 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...


This sounds good to me, speaking as a non-developer, but there is still the
issue that staff would have to actively select an alternate classification
scheme whenever they override the library default. It may be a tradeoff that
needs to be made, but I hate to add to the workflow, especially since
catalogers will likely be adding large batches of items at one time that
deviate from the default.
> 
> 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.

[KL] When I was reviewing the previous discussion about LC sorting, Jason
Etheridge had suggested the possibility of nesting sort algorithms -
http://markmail.org/message/xxbfp63g3yzeqxqa. A possible configuration could
be:

Sort #1 -> LCCN 
Sort #2 -> DDS
Sort #3 -> Default / ASCIIbetically

I think this is what we have in mind for sorting across schemes.

> 
> >
> > 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.

[KL] Printing spine labels is just one piece of this, but generating reports
based on call number ranges is another big piece. I like the idea of knowing
that the data contained within the call number field is truly the call
number. If we're generating a call number report for one library, it may be
easy enough to account for whatever prefix may be in the call number field,
but if we're generating reports that look at trends for the entire
consortium with libraries using a variety of prefixes, I'm guessing it would
become a little more complicated.

Adding the prefix and suffix to the copy location may be a good solution.

Thanks to everyone for their feedback!

Kathy Lussier

-------------------------------------------------------------

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 756-0172
(508) 755-3721 (fax)
klussier at masslnc.org