[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: Joshua Ferraro
Subject: Re: [Koha-devel] Some script ideas on version 3
Date: Fri, 17 Mar 2006 10:01:40 -0800
User-agent: Mutt/1.4.1i

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:


In this case, 'SF' stands for 'science fiction'.

Compare that call number with the more standard Dewey call number here:


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


President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS

reply via email to

[Prev in Thread] Current Thread [Next in Thread]