OpenBiblio

There's a big table (over 12,000 rows) and a fair amount of code in the lookup module devoted to generating call numbers with Cutter-Sanborn or LOC Cutter codes. Do either of you use this code? My feeling is that call number generation should be done outside OpenBiblio. Libraries with less than 100,000 items are probably 99% of OpenBiblio's potential audience, and I don't see complex, generated call numbers making much sense at that size. Aside from that, there's no one standard for us to support. If we support Cutter-Sanborn 3-Figure codes, I don't have an argument for why that's more appropriate than Cutter 2-Figure or OCLC 4-Figure codes, and I certainly don't want to support all of them. I'm all for enabling MARC import to load the call number from any MARC field, but I think further call-number processing is best left out of OpenBiblio. From my perspective, it adds complexity with no benefit for most users. Thoughts? Micah

I have no thoughts, as I don't understand exactly what it does and have disabled it in tools , so no real thoughts on that.

I use LOC cutters here at home, Our local Library uses the CS3 cutters. But aside from that I would guess that about one half of my email regarding Lookup is in response to use of call number and cutter generation. Perhaps large libraries have the budget for people to do that kind of work but those in small towns (under 1000 souls) seem to have a single person to do everything and essentially no budget. I think the size of the cutter table is a non-issue in these days of tera-byte storage for $100. The code involved is small too I think. Had I thought this sort of thing would come up I would not have integrated lookup at all.

I'm not saying libraries should hire staff to generate complex call numbers, I'm saying small- to medium-sized libraries don't need complex call numbers. I've never heard of a small library using cutter numbers before now. All the libraries I use or support use a Dewey decimal number followed by the first few letters of the author's last name for their main non-fiction collection. These collections range in size from a few thousand to several hundred thousand. There's only one reason I know for using cutter numbers: it can speed up shelving of items when you have many books that would otherwise have the same call number. For most libraries, a simpler system like the one above doesn't result in too many duplicate call numbers, so the additional complexity isn't worth it. I'm curious to know why the two libraries you're talking about chose to adopt cutter numbers, and what it buys them. I'd like to talk about the code size issues over in the Tools Section thread, since it fits there. Micah