Filtering inventory results by cn_sort vs. callnumber
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
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@nps.gov Library catalog: http://keys.bywatersolutions.com/
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@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@nps.gov Library catalog: http://keys.bywatersolutions.com/ _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
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, heather_hernandez@nps.gov Library catalog: http://keys.bywatersolutions.com/
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@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@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@nps.gov Library catalog: http://keys.bywatersolutions.com/ _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@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@lancasterseminary.edu https://library.lancasterseminary.edu
Hi! Thank you, Myka, for that report to see if cn_sort does sort LC call numbers with colons in the cutters correctly! Unfortunately, it doesn't. The following not come across clearly, but here are some results from running that report in our catalog on the G class schedule--if anyone would like to see this live, let me know & I'll make the report/output public in our OPAC: 192284 G4363 V4 A1 1921 G46 1928 G4363 V4 A1 01921 G00046 01928 lcc G4364 S5:2 C45 1885 F3a G4364 S00005:00002 C00045 018 lcc 158187 G4364 S5:2 P7 E635 1980 H5 G4364 S00005:00002 P00007 E00635 01980 H00005 lcc 183574 G4364 S5:2 S68 E15 1980 A44 G4364 S00005:00002 S00068 E00015 01980 A00044 lcc 183572 G4364 S5:2 S68 E15 1980 A44 G4364 S00005:00002 S00068 E00015 01980 A00044 lcc 100334 G4364 S5:2 W33 1922 C34 G4364 S00005:00002 W00033 01922 C00034 lcc 100020 G4364 S5:2 W33 1922 C34 G4364 S00005:00002 W00033 01922 C00034 lcc G4364 S5:2 W33 1922 C34a G4364 S00005:00002 W00033 01922 C00034A lcc 191312 G4364 S5:2 W33 H36 G4364 S00005:00002 W00033 H00036 lcc 100125 G4364 S5:2 W36 1915 P36 G4364 S00005:00002 W00036 01915 P00036 lcc G4364 S5:2 W36 1915 P36a G4364 S00005:00002 W00036 01915 P00036A lcc 189915 G4364 D22 P54 1889 U8 1890 G4364 D22 P54 01889 U00008 01890 lcc 191315 G4364 E9 1965 E97 G4364 E9 01965 E00097 lcc 192172 G4364 L663 P5 1889 U8 G4364 L663 P5 01889 U00008 lcc G4364 L663 P5 1889 U8 G4364 L663 P5 01889 U00008 lcc 106731 G4364 O2 1939 B45 G4364 O2 01939 B00045 lcc 100023 G4364 P2 A1 1899 U5 1979 G4364 P2 A1 01899 U00005 01979 lcc 170703 G4364 P7 A3 1880 E45 1977 G4364 P7 A3 01880 E00045 01977 lcc All the call numbers with the cutter "S5:2" are filing before cutters in the rest of the alphabet, where they should be filing after "S5," and certainly after all the call numbers after them in the above example. So for the purposes of the bug under discussion, it's probably great to use cn_sort! But if any collection that uses LC classification has cartographic materials (maps, charts, etc.) cataloged in these G areas & follows LC practice of the cutters with colons in them, the fact that they don't sort correctly is something to be aware of. A bug about it has been created, Bug 17269 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269>, but there's been no activity on it. This report is also really useful for spotting formatting errors in call numbers! If there were any. I'm not admitting anything.:):):) 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, heather_hernandez@nps.gov Library catalog: http://keys.bywatersolutions.com/ On Thu, Nov 15, 2018 at 5:56 PM Myka Kennedy Stephens < mkstephens@lancasterseminary.edu> wrote:
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.
(snip)
participants (4)
-
Eric Phetteplace -
Hernandez, Heather -
Myka Kennedy Stephens -
Nick Clemens