[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Koha-devel] Some script ideas on version 3
From: |
Tümer Garip |
Subject: |
RE: [Koha-devel] Some script ideas on version 3 |
Date: |
Thu, 16 Mar 2006 23:48:30 +0200 |
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:address@hidden
Sent: Thursday, March 16, 2006 6:01 PM
To: Tümer Garip
Cc: 'Paul POULAIN'; address@hidden
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
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS