On Thu, Mar 16, 2006 at 11:48:30PM +0200, Tümer Garip wrote:
Hi, Joshua said:
In fact, aren't there cases where a library uses two or more different item call numbers for different collections? For instance, NPL uses Dewey for non-fiction >>but fiction uses a locally-constructed method.
So in addition to needing to parse multiple subfields it should also support multiple mappings ... Any suggestions for how to handle that? Well I am not so sure of what you ment but if you mean parsing 050a,050b,090b,245c altogether to form the itemcalnumber from whichever combination there is i.e just combine them in order as long as there is something in these fields thats easy (we can write that). If not explain what the need is in layman terms as we dont know what you use. What you describe is yet another function that would be nice to have but is a bit different than NPL's need :-). I will try to explain. NPL has two classification systems, one for non-fiction (Dewey) and one for fiction (two letter code for type of fiction followed by author's last name). You can view an example of this on NPL's catalog:
http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-detail.pl?bib=16595 In this case, 'SF' stands for 'science fiction'. Compare that call number with the more standard Dewey call number here: http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-detail.pl?bib=51475 This makes it quite difficult to do a search by call number or classification (NPL doesn't distinguish between these two). Does that make more sense? Any suggestions for how to handle this?
What kinds of tweaking would be necessary? Well I think the code can be written more intuitevly rather than assuming that the cataloger have put say the dot in the correct place or not. All the fields are doubles while some can be left as text etc. The code does work by the way just that it need more thought for flexibility Sounds like some good improvements ...
Sincerely, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS