Bug 2500 - Standing enhancement request for adding/updating call number splitting algorithms in C4/Labels.pm
Summary: Standing enhancement request for adding/updating call number splitting algori...
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Label/patron card printing (show other bugs)
Version: unspecified
Hardware: PC All
: P3 enhancement (vote)
Assignee: Chris Nighswonger
QA Contact: Bugs List
URL:
Keywords:
Depends on: 9370
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-09 10:59 UTC by Chris Cormack
Modified: 2019-05-06 13:06 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Patch to correct incorrect cutter number splitting (10.58 KB, patch)
2009-09-14 15:58 UTC, Chris Cormack
Details | Diff | Splinter Review
Corrected patch to make TAP::Parser happy (13.31 KB, patch)
2009-09-15 13:29 UTC, Chris Cormack
Details | Diff | Splinter Review
Split LCCN on "segmentation" markers: '/' (1.58 KB, patch)
2011-03-14 21:38 UTC, Chris Nighswonger
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:51:53 UTC


---- 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.

Comment 1 Chris Nighswonger 2011-03-14 21:35:02 UTC
Adding code to accommodate LCCN numbers containing "segmentation" markers.

Ie. 917.1/0022/2 which is expected to split to 917.1 0022 2
Comment 2 Chris Nighswonger 2011-03-14 21:38:52 UTC Comment hidden (obsolete)
Comment 3 Chris Nighswonger 2011-03-14 21:44:58 UTC
(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
Comment 4 MJ Ray (software.coop) 2011-04-10 11:25:40 UTC
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
Comment 5 Katrin Fischer 2011-04-25 11:44:33 UTC
What's the status of this? I see a patch but not sure it was pushed, needs rebasing or sign-off.
Comment 6 Nicole C. Engard 2011-04-25 12:29:45 UTC
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.
Comment 7 Katrin Fischer 2011-04-25 12:45:10 UTC
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.
Comment 8 Chris Nighswonger 2011-04-25 13:50:55 UTC
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.
Comment 9 Katrin Fischer 2011-04-25 14:08:51 UTC
Ok, leaving open.
Comment 10 Jared Camins-Esakov 2012-02-25 20:35:04 UTC
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.
Comment 11 Chris Nighswonger 2012-02-25 21:17:43 UTC
(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 12 Chris Nighswonger 2012-02-25 21:19:36 UTC
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.
Comment 13 Jared Camins-Esakov 2012-02-25 21:21:52 UTC
(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.
Comment 14 Chris Nighswonger 2012-02-26 01:25:09 UTC
(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 15 Galen Charlton 2013-01-09 01:40:32 UTC
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.
Comment 16 Galen Charlton 2013-01-09 01:59:15 UTC
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.
Comment 17 Iming Chan 2013-07-14 06:08:39 UTC
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
Comment 18 David Cook 2013-08-26 01:35:59 UTC
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...
Comment 19 Tom Misilo 2016-03-23 13:28:24 UTC
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
Comment 20 Katrin Fischer 2018-12-18 22:31:48 UTC
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
Comment 21 Joelle Hannert 2019-05-06 13:06:47 UTC
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