---- Reported by chris.nighswonger@liblime.com 2008-08-09 10:59:52 ---- Call numbers that do not split correctly should be added to this enhancement request. The following information should be supplied: 1. The call number in question. 2. The formal name of the classification system (ie. LOC, Dewey, etc.) 3. Any other information you feel may be helpful. ---- Additional Comments From gmcharlt@gmail.com 2009-03-04 07:33:21 ---- Pushed 2/26 patch to HEAD. ---- Additional Comments From joe.atzberger@liblime.com 2009-03-09 13:51:26 ---- Bigger patch sent. ---- Additional Comments From cnighswonger@foundations.edu 2009-05-27 15:40:22 ---- Presently 252.051 T147 v.1-2 is split as 252.051 T147 v.1 -2 Submitted patch corrects the algorithm so that it splits as 252.051 T147 v.1-2 It also updates Labels_split_ddcn.t to include this particular case. ---- Additional Comments From gmcharlt@gmail.com 2009-05-27 15:49:55 ---- Pushed 5/27 patch to HEAD. ---- Additional Comments From cnighswonger@foundations.edu 2009-09-14 15:52:52 ---- '302.23 P338m' and the like does not split as: 302.23 P338m but as 302.23 P338 m as reported by Scotty Zollars Director of Library Services Labette Community College ---- Additional Comments From cnighswonger@foundations.edu 2009-09-14 15:58:08 ---- Created an attachment Patch to correct incorrect cutter number splitting ---- Additional Comments From cnighswonger@foundations.edu 2009-09-15 13:29:11 ---- Created an attachment Corrected patch to make TAP::Parser happy ---- Additional Comments From cnighswonger@foundations.edu 2009-09-15 15:41:51 ---- *** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3636 has been marked as a duplicate of this bug. *** ---- Additional Comments From gmcharlt@gmail.com 2009-09-16 00:30:30 ---- Pushed latest patch to HEAD. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:51 UTC --- This bug was previously known as _bug_ 2500 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2500 Imported an attachment (id=684) Imported an attachment (id=685) Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was chris.nighswonger@liblime.com. CC member pratheci@oplin.org does not have an account here CC member scottz@labette.edu does not have an account here The original submitter of attachment 684 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 685 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Adding code to accommodate LCCN numbers containing "segmentation" markers. Ie. 917.1/0022/2 which is expected to split to 917.1 0022 2
Created attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/'
(In reply to comment #2) > Created attachment 3298 [details] [review] > Split LCCN on "segmentation" markers: '/' This patch may also be picked up here: http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=commit;h=b1cab59d94670817eb4955ac9ad324f98ed7918d
This bug is mentioned in: Bug 2500 - Standing enhancement request for adding/updating call number splitting algorithms in C4/Labels.pm http://lists.koha-community.org/pipermail/koha-patches/2011-March/014049.html
What's the status of this? I see a patch but not sure it was pushed, needs rebasing or sign-off.
I think the 'standing issue' part of the title means that as people report problems with splitting this is the bug to use to attach the patches to.
Hi Nicole, I agree :) But there is a patch and I wondered if that was integrated or not since I found no 'patch pushed' status or comment for the patch attached last to the bug.
There are actually more patches under this bug than are attached, IIRC. Both of these patches have been pushed. (The first no longer applies as there is not label.pm any longer) I'm not sure that changing the priority of this bug or listing as "patch-pushed" etc. makes sense in light of this being a standing enhancement request. Changing these from the default status would imply that every patch submitted was at that status level which may not be true.
Ok, leaving open.
Comment on attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' LCCNs do not have segmentation markers. The example is for DDC, and the feature is already implemented for that classification.
(In reply to comment #10) > Comment on attachment 3298 [details] [review] > Split LCCN on "segmentation" markers: '/' > > LCCNs do not have segmentation markers. The example is for DDC, and the feature > is already implemented for that classification. IIRC this was specifically added at the request of someone on the mailing list. See http://koha.1045719.n5.nabble.com/Split-Call-Numbers-Variation-td3556413.html#a3621392 From this statement: "That's kind of surprising, I have been playing around a bit on my test box and for me Library of Congress numbers never seem to get split. They usually come in this format: 917.1/0022/2 which always shows up on my labels as 917.100222 and that is obviously too long." in one of the posts, it appears that at least one person does get LCCN numbers with a '/' as a segmentation marker.
Comment on attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' Removing obsolete because this has been requested and should make no difference to LCCN numbering which contains no sort of segmentation markers.
(In reply to comment #11) > (In reply to comment #10) > > Comment on attachment 3298 [details] [review] > > Split LCCN on "segmentation" markers: '/' > > > > LCCNs do not have segmentation markers. The example is for DDC, and the feature > > is already implemented for that classification. > > IIRC this was specifically added at the request of someone on the mailing list. > See > http://koha.1045719.n5.nabble.com/Split-Call-Numbers-Variation-td3556413.html#a3621392 > > From this statement: > > "That's kind of surprising, I have been playing around a bit on my test box and > for me Library of Congress numbers never seem to get split. They usually come > in this format: 917.1/0022/2 which always shows up on my labels as 917.100222 > and that is obviously too long." in one of the posts, it appears that at least > one person does get LCCN numbers with a '/' as a segmentation marker. Ah, I assumed it was a typo for ddcn that wasn't applied because the issue was identified as user error, since the example given is a DDC call number not an LC call number. Sorry about that.
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > Comment on attachment 3298 [details] [review] > > > Split LCCN on "segmentation" markers: '/' > > > > > > LCCNs do not have segmentation markers. The example is for DDC, and the feature > > > is already implemented for that classification. > > > > IIRC this was specifically added at the request of someone on the mailing list. > > See > > http://koha.1045719.n5.nabble.com/Split-Call-Numbers-Variation-td3556413.html#a3621392 > > > > From this statement: > > > > "That's kind of surprising, I have been playing around a bit on my test box and > > for me Library of Congress numbers never seem to get split. They usually come > > in this format: 917.1/0022/2 which always shows up on my labels as 917.100222 > > and that is obviously too long." in one of the posts, it appears that at least > > one person does get LCCN numbers with a '/' as a segmentation marker. > > Ah, I assumed it was a typo for ddcn that wasn't applied because the issue was > identified as user error, since the example given is a DDC call number not an > LC call number. Sorry about that. Sorry. As you can see, I took what was requested and added it assuming the requester knew what he/she was talking about. I'm by no means a call number expert. :-) If this is not a valid LCCN, then feel free to correct and/or obsolete.
Comment on attachment 3298 [details] [review] Split LCCN on "segmentation" markers: '/' 917.1/0022/2 is indeed a Dewey call number, not an LC call number, and I agree with Jared that LC call numbers aren't entered with segmentation marks. Consequence, as your previous comment indicated, I'm marking the patch as obsolete.
For the record, I'm adding the following example to this standing bug: The LC number 'QH541.15.C6 C25 2012' is currently being split like this: QH 541 .15 .C6 C25 2012 It should actually be split as follows: QH 541.15 .C6 C25 2012 However, the fix for this is being handled via bug 9370, which is proposing using a CPAN module to handle LC call number parsing.
Hello, 1. The DDC number: 629.283042 2. Class format: Dewey 3. I would like the call number to appear as: 629. 283 042 Automatically text wrap in groups of three after the decimal point. This is how spine labels from our previous system generated, and fits perfectly to our current stationery. Please also keep <space> (found in the current splitting algorithm) as this is useful for call number like: DVD 629.283042 FRAS to appear as: DVD 629. 283 042 FRAS
So I've recently encountered a call number like this: 361.250994 REP NO. 11/10 The section "361.250994" is DDC, I believe. However, "REP NO. 11/10" is entirely local. When printing labels and splitting call numbers, the slash between 11 and 10 gets removed using _split_ddcn. This isn't desirable, so I opted to use a different splitting sub. However, if I use _split_ccn, "REP NO. 11/10" gets turns into "REP NO. 11 /10", which is also undesirable, as that means "11" gets printed on one line and "/10" gets printed on the next. This is due to some regexp found in _split_ccn, which pulls apart the last element in the @parts array. Is there are a reason why the last element in the array is being pulled apart like this? I used git blame but the original 2009 commit message from Chris Nighswonger didn't really tell me much. I'm sure there is a reason, but it might make more sense for this - or another - sub to just split on spaces. -- Another thought...currently there is no way to associate splitting subs with call number classification schemes. The only way I see is to hardcode it into Label.pm. Perhaps it would be an idea to specify the call number splitting rule in the "Classification sources" part of the Administration module. This could be useful in several contexts. For instance, we're currently using the _split_lccn sub for LCC and NLM, but it could also be useful for the KF Modified classification scheme (which is a legal scheme based on LCC) and other schemes. KDC (Korean Decimal Classification) would also probably use DDC. Admittedly, since the behaviours are likely the same, people using KF Modified or KDC should probably just use "LCC" or "DDC" as classification sources rather than making new ones, so perhaps I don't actually have a good point there :p. However...there might be times when a library wants to use the DDC filing rules but have call number splitting just on spaces. Like in the above case where they want to preserve those local slashes. I don't know. Just a thought. I've already set up "z" to use _split_ccn in the past. I might adjust it so that it uses a different sub which just split on spaces...
1. The call number in question. C 3.278/3:996/9 C 3.278/3:995/2 C 3.278/3:999/5 ... 2. The formal name of the classification system (ie. LOC, Dewey, etc.) SuDoc Superintendent of Documents (SuDocs) Classification Scheme 3. Any other information you feel may be helpful. http://libweb.lib.georgiasouthern.edu/wiki/index.php/Sample_Gov_Docs_Spine_Labels
This new dev might help a bit, we could add slitting rule definitions to the wiki if there is interest too (similar to the SQL or Serial pattern libraries): Bug 15836 - Labels: Offer configuration option for splitting call numbers
I'm having problems with two types of call number splits in LC; children's literature and numbers that incorporate a military regiment. Here are examples of each: Children's lit example: PZ7.1 .P6213 St 2018 appears as PZ 7.1 .P6213 S T2018 I would like it to be split as PZ 7.1 .P6213 St 2018 Military regiment example: E492.94 1st .H53 1982 appears as E 492.94 1 .S T H53 1982 I would like it to be split as E 492.94 1st .H53 1982