[Bug 17269] New: Library::CallNumber:: LC does not follow LC standards for Area Subarrangments of cataloged maps
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 Bug ID: 17269 Summary: Library::CallNumber::LC does not follow LC standards for Area Subarrangments of cataloged maps Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt@gmail.com Reporter: barton@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org Library::CallNumber::LC is used to generate cn_sort for Library of Congress callnumbers. According to the LC document "Special Instructions and Tables of Subdivisions for Cartographic Materials", in the section 'Area Subarrangments' The document can be found at http://www.loc.gov/catdir/cpso/class_g.pdf; see page 6: "Regions and political divisions within a city or town may be classified with the use of a colon (:) followed by the number 2 or 3, indicating whether the subdivision is (2) geographic or (3) political and a Cutter number for the subdivision. Examples: G4364 California (map city and town number) .L8:2G7 Los Angeles, Griffith Park (classified as a region) G4114 Michigan (map city and town number) .E4:2M4 East Lansing, Michigan State University (classified as a region) G3804 New York State (map city and town number) .N4:3Q4 New York City, Queens (classified as a political division) " When I use Library::CallNumber::LC::Normalize(), 'G4364 .L8:2G7' and 'G4364 .L8' generate entirely different call numbers: Library::CallNumber::LC->normalize("G4364 .L8:2G7") => G4364 .L00008:00002G00007 Library::CallNumber::LC->normalize("G4364 .L8") => G4364 L8 If I'm reading the Library of Congress instructions instructions correctly, I believe that "G4364 .L8:2G7" should generate as "G4364 L8:2G7", which would sort after "G4364 L8", whereas "G4364 .L00008:00002G00007" sorts before "G4364 L8". I'm also filing a bug with the module maintainer: https://github.com/libraryhackers/library-callnumber-lc/issues/10 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 Heather <heather_hernandez@nps.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |heather_hernandez@nps.gov -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 --- Comment #1 from Heather <heather_hernandez@nps.gov> --- We just got Elasticsearch, and these call numbers with colons in them appear to be sorting correctly: https://keys.bywatersolutions.com/cgi-bin/koha/opac-search.pl?q=callnum%2Cphr%3Ag4364&offset=40&sort_by=call_number_asc Our Koha version is 19.05.07.000 --h2 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@koha-us.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 --- Comment #2 from Heather <heather_hernandez@nps.gov> --- We're now on 21.05 with Elasticsearch and the call numbers are no longer sorting correctly--call numbers with the cutter S5:2 are sorting before S5. --h2 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Heather from comment #2)
We're now on 21.05 with Elasticsearch and the call numbers are no longer sorting correctly--call numbers with the cutter S5:2 are sorting before S5.
--h2
Hi Heather! I think you might be seeing Bug 29632 - Callnumber sorting is incorrect in Elasticsearch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 --- Comment #4 from Heather <heather_hernandez@nps.gov> --- (In reply to Katrin Fischer from comment #3) It sure could be, Katrin! Nick Clemens filed bug 29632 just a few days ago--maybe that's a duplicate of this one? Or that's a better written/better one than this one, which has been languishing for years? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think Barton's bug was about a possible issue with the library we use to generate the cn_sort - the sortable form of the callnumber - for LC callnumbers. As this should be fixed by the maintainers of this library, he has filed it here: https://github.com/libraryhackers/library-callnumber-lc/issues/10 If things have worked ok for you before, they will probably work ok once Elasticsearch uses cn_sort for sorting as well. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org