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 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
Cheers, Tumer Garip NEU Libraries & Information Systems Director -----Original Message----- From: Joshua Ferraro [mailto:jmf@liblime.com] Sent: Thursday, March 16, 2006 6:01 PM To: Tümer Garip Cc: 'Paul POULAIN'; koha-devel@nongnu.org Subject: Re: [Koha-devel] Some script ideas on version 3 On Thu, Mar 16, 2006 at 05:52:12PM +0200, Tümer Garip wrote:
Hi all, I don't know whether everything is set for v3 KOHA but here are some food for thought. No, not set completely yet.
In our library we use LC classification and callnumbering.
1- For this the item call number is constructed from MARC21 field 050a
and 050b plus ant other local addition. KOHA has a system preference for putting only one subfield into itemcallnumber. Couldn't we have it
so that if we write 050ab it actually parses and reads both subfields or maybe even better 050a,XXXb for real flexibility. 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?
2- Inventory reports are supposed to order the books as they appear on
the shelf. For us (LC) order goes like this:
AB1.5 C25 2004 AB1.5 C203 2004 AB5 .C203 2004 AB41 .C203 2004 AB234 .C203 2004 (just samples not real callnumbers) This sorting is a litte complex that letters are sorted as text and numbers as numbers.
While KOHA sorts them as a text field and we have AB1.5 C203 2004 AB1.5 C25 2004 AB234 .C203 2004 AB41 .C203 2004 AB5 .C203 2004
To be able to achieve the LC sort order we had to write a parsing routine to item callnumber and add 5 more fields to items table.
If this is an issue for others as well may be we can incorporate it in
official release with a system preference whether to use this sorting or not. Yes!!! Please do.
I need to know whether it is useful to you so we can start tweaking this module which is not on our priorities list. What kinds of tweaking would be necessary?
Cheers, -- 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