Discussion:
[Koha] Filtering inventory results by cn_sort vs. callnumber
Nick Clemens
2018-11-14 12:12:14 UTC
Permalink
Hello All!

I put together a bug a while back for switching the sorting on inventory
results filter from using 'callnumber' to the hidden/constructed column
'cn_sort'

i.e. When inventorying a section by callnumber you would enter the range
GT90 to GT100, Koha would then interpret this to (roughly) GT090 and GT100
as we do when constructing the cn_sort column.

'cn_sort' is the column we use to pad callnumbers with '0' and spaces to
ensure that a callnumber of GT90 is sorted before GT100 (if sorted as
normal strings 1 comes before 9)

During review if the bug there was concern that some callnumber schemes may
not work under this change, or some libraries might not have the cn_sort
columns correctly filled and that we should add a system preference to
control which column was used.

On bug 21629 (
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21629) we made
sorting lists by callnumber use cn_sort by default.

I am just writing to see if any libraries out there have concerns about the
change, or if we think that always using cn_sort to filter the results
would work. We want to be consistent throughtout the code (ideally)

Let me know what thoughts you have and if you think we can simply assume
cn_sort is the definitive column for sorting and defining ranges.

-Nick
--
Nick Clemens
Sonic Screwdriver (Development Support)
ByWater Solutions
IRC: kidclamp
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/
Hernandez, Heather
2018-11-15 16:01:05 UTC
Permalink
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, ***@nps.gov
Library catalog: http://keys.bywatersolutions.com/
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.katipo.
Eric Phetteplace
2018-11-15 20:56:54 UTC
Permalink
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 <
Post by Hernandez, Heather
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
Library catalog: http://keys.bywatersolutions.com/
_______________________________________________
Koha mailing list http://koha-community.org
https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
htt
Hernandez, Heather
2018-11-15 22:24:57 UTC
Permalink
Thank you, Eric!

Cheerio,
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, ***@nps.gov
Library catalog: http://keys.bywatersolutions.com/
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.katipo.co.nz
Myka Kennedy Stephens
2018-11-16 01:54:02 UTC
Permalink
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
Post by Eric Phetteplace
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 <
Post by Hernandez, Heather
Hi, Nick--
I read through Bug 21629 and if I'm reading it correctly, it says that
call
Post by Hernandez, Heather
numbers are sorted correctly using cn_sort, but Bug 17269 describes how
call numbers are not sorted correctly using cn_sort, specifically the
ones
Post by Hernandez, Heather
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
Post by Hernandez, Heather
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
Library catalog: http://keys.bywatersolutions.com/
_______________________________________________
Koha mailing list http://koha-community.org
https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list http://koha-community.org
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
***@lancasterseminary.edu
https://library.lancasterseminary.edu
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listi
Loading...