[Koha] [EXTERNAL] Filtering inventory results by cn_sort vs. callnumber

[Myka Kennedy Stephens]

To Heather: I'm the one who reported and signed off on Bug 21629.
Unfortunately, I did not test it with any LC numbers with colons in them.
We don't have any items in our catalog with those types of numbers, so
that's not been an issue that's affected us. An easy way to check and see
if cn_sort does correctly sort those types of call numbers would be to
write a simple shelf list report. Here's an example that someone at ByWater
wrote for us a few years ago to test the reliability of cn_sort:

select barcode, itemcallnumber,cn_sort, cn_source from items where
itemcallnumber like "B%" order by cn_sort

You could change "B%" to "G%" for it to return a list of everything in your
catalog from the G class.

Responding to Eric: I agree that having the inventory tool use cn_sort
would be a huge help, and I don't think it necessarily needs a system
preference to control it. Does cn_sort work just as well with Dewey numbers
as LC? I also like the idea of being able to create new normalization
schemes for custom classification sources. I must admit, though, have not
experimented with customizing the classification sources in Koha. It seems
to be limited, and I haven't seen a particular need. There are only three
predefined classification filing rules that can be used by a classification
scheme. While you can create a new filing rule, you are given only three
options for sorting/filing routines. How does one create or upload an
additional sorting/filing routine? (Note: the terminology is not consistent
for the routines.) Could these routines then be used or assigned to a
specific cn_sort profile, as Eric suggests? Would it be necessary to define
specific cn_sort profiles, or does the sorting/filing routine already
inform how cn_sort behaves on the basis of which classification source an
item uses?

Taking another look at the bug that Heather mentioned (17269), could this
be due to a problem with the LCC sorting/filing routine? If there is a way
to edit those routines (which I can't find in Administration), that might
provide a sufficient level of control that libraries would need to make
sure that cn_sort works for their needs. It wouldn't necessarily require a
system preference to turn off/on using cn_sort for various things (like
inventory), but how classification sources and filing rules are managed may
need another look.

One other observation: We created a new in house system for our special
collections, and we currently use z - other/generic for the classification
source, which uses the generic filing rule linked to the Generic
sorting/filing routine. We noticed that our in house system plays well with
the shelf browser in the OPAC and with cn_sort in a report, but not the
call number browser in the staff client when you're editing items. Since we
self-assign these call numbers, it would be super-helpful if the staff
client's call number browser could help us identify call numbers already in
use so that we don't assign duplicates when we're reclassifying items. That
is bug #18499, which also seems to be tied up with this bug (19915) for
switching the inventory tool to cn_sort.

Hope all that is helpful and not complicating the matter,
Myka

On Thu, Nov 15, 2018 at 3:57 PM Eric Phetteplace <ephetteplace at cca.edu>
wrote:

> I'm in support of using cn_sort wherever sorting occurs as that's its
> purpose. If I'm not mistaken, it's already being used in some places
> without an existing system preference, and I don't see how the Inventory
> tool is categorically different. Is it possible, perhaps in a plugin, to
> configure new normalization methods for different classification sources?
> That seems to be the purpose of the Classification Sources admin settings
> but I'm not sure.
>
> To answer Heather—I think your second question is correct, the two problems
> are not intertwined. One deals with LC numbers being improperly normalized
> and another deals with the normalized strings not being used as the sorting
> value in places.
>
> Best,
>
> ERIC PHETTEPLACE
>
> Systems Librarian
>
>
> libraries.cca.edu | vault.cca.edu | 510.594.3660
>
> 5212 Broadway, Oakland, CA 94618
>
> 1111 8th St., San Francisco, CA 94107
>
> Preferred Pronoun(s): he/him
>
> :(){ :|: & };:
>
>
> On Thu, Nov 15, 2018 at 8:01 AM Hernandez, Heather <
> heather_hernandez at nps.gov> wrote:
>
> > Hi, Nick--
> >
> > I read through Bug 21629 and if I'm reading it correctly, it says that
> call
> > numbers are sorted correctly using cn_sort, but Bug 17269 describes how
> > call numbers are not sorted correctly using cn_sort, specifically the
> ones
> > with colons in them in the G Library of Congress classification schedule.
> >
> > Has Bug 21629 been tested using LC call numbers with colons in them?  Or
> is
> > the problem of incorrect sorts of LC call numbers with colons in them
> > unrelated?
> >
> > Thank you!  Cheers,
> > h2
> > ~~~~~~~~~~~~~~
> > Heather Hernandez
> > Technical Services Librarian
> > San Francisco Maritime National Historical Park Research Center
> > 2 Marina Blvd., Bldg. E, 3rd floor, San Francisco, CA  94123-1284
> > 415-561-7032, heather_hernandez at nps.gov
> > Library catalog: http://keys.bywatersolutions.com/
> > _______________________________________________
> > Koha mailing list  http://koha-community.org
> > Koha at lists.katipo.co.nz
> > https://lists.katipo.co.nz/mailman/listinfo/koha
> >
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>


-- 
Deaconess Myka Kennedy Stephens, MDiv, MSLIS
Seminary Librarian and Assistant Professor of Theological Bibliography
Lancaster Theological Seminary
555 West James Street
Lancaster, PA 17603
717-290-8704
mkstephens at lancasterseminary.edu
https://library.lancasterseminary.edu