Re: [Koha] More questions - another 2 cents worth
Monday, June 16, 2003 12:40 CDT Greetings, all! I don't know if it's possible, but perhaps until the developers can create a classification field that uses ANY system/s the users need, it might be useful to have stop-gap 'DDC' and 'LC' versions of Koha. Ed is dead-on in noting that LC is really the standard for scientific libraries. I interviewed on one that insisted in using Dewey a few years ago: most of the call numbers were 20 digits. Not fun to try to use or communicate to users. Anyway, that's just my 2 cents worth, Cheers, Steven F. Baljkas Koha neophyte, Winnipeg MB CANADA P.S. To be honest, I've also thought that it would be good to have MARC21 and UNIMARC versions as well; might simplify some mapping problems interim.
On Mon, Jun 16, 2003 at 12:44:31PM -0500, baljkas@mb.sympatico.ca said:
Monday, June 16, 2003 12:40 CDT
Greetings, all!
I don't know if it's possible, but perhaps until the developers can create a classification field that uses ANY system/s the users need, it might be useful to have stop-gap 'DDC' and 'LC' versions of Koha. Ed is dead-on in noting that LC is really the standard for scientific libraries. I interviewed on one that insisted in using Dewey a few years ago: most of the call numbers were 20 digits. Not fun to try to use or communicate to users.
We do have an lccn field in the koha database. And you can load data into it, its currently not displaying or searchable yet though. This is a templating issue, im sure we could change it quite fast.
P.S. To be honest, I've also thought that it would be good to have MARC21 and UNIMARC versions as well; might simplify some mapping problems interim.
In the 1.9.x (soon to be 2.0) tree, MARC21 and UNIMARC are fully supported, so using the MARC search u can search LC with it. Its just the old search interface that would need tweaking to allow LC searching. I hope this makes sense, (im currently on the other side of the world from home, and slightly sleep deprived so i wouldnt be suprised if it doesnt :-)) Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
I think there may be some confusion between a lccn number (library of congress control number) and library of congress call numbers. If I understand correctly, a lccn number is single unique number used to identify a specific title, kind of like a serial number. However, (librarians, please correct me if I'm wrong) lccn numbers are not used for cataloging and shelving books in a library that used the LC system. Instead there are a series of four or five lines of call numbers that are used instead. Rather than try to explain it, let me refer you to http://www.lib.ksu.edu/instructional/understandinglccn/webcall2.html or http://www.hcc.hawaii.edu/education/hcc/library/callno.html for some explanation and samples of LC call numbers. The problem is that koha doesn't currently have adequate fields of the proper type for storing these four or five lines of information in the database (I think there are such fields in the MARC tables, but not in the basic koha tables). I agree that accommodating the different cataloging systems is a template issue, but feel that the necessary fields need to be in place in the database tables first. I had actually emailed the development list on this same issue a couple weeks ago (subject: inflexible field types for call numbers). My recommendation would be that we survey as many knowledgeable librarians as possible to find out how many fields are necessary for storing call numbers under the various systems, what the maximum length of each needs to be, and then add those fields to the database tables (unless the programmers could suggest existing fields that can be used). I think if there were four or five flexible fields for storing call number information, then indeed koha could be adapted to almost any cataloging system by reworking the templates. Rob ----- Original Message ----- From: "Chris Cormack" <chris@katipo.co.nz> Sent: Tuesday, June 17, 2003 1:20 AM Subject: Re: [Koha] More questions - another 2 cents worth
We do have an lccn field in the koha database. And you can load data into it, its currently not displaying or searchable yet though. This is a templating issue, im sure we could change it quite fast.
On Tue, Jun 17, 2003 at 01:48:43PM -0500, robweir@alum.drexel.edu said:
I think there may be some confusion between a lccn number (library of congress control number) and library of congress call numbers. If I understand correctly, a lccn number is single unique number used to identify a specific title, kind of like a serial number. However, (librarians, please correct me if I'm wrong) lccn numbers are not used for cataloging and shelving books in a library that used the LC system. Instead there are a series of four or five lines of call numbers that are used instead.
Rather than try to explain it, let me refer you to http://www.lib.ksu.edu/instructional/understandinglccn/webcall2.html or http://www.hcc.hawaii.edu/education/hcc/library/callno.html for some explanation and samples of LC call numbers.
AHhh it all becomes clear :-) Yep, that makes much more sense. I think ive seen the first new thing for the upcoming 2.1.x tree :-) We are in feature freeze currently heading into the release of 2.0 but as soon as thats stable enough, we can start development on new features. It might be good to start a page on the wiki where ppl can build a plan for handling the differing call numbers. Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Thanks for the feedback Chris. I would like to lobby for at least including the new fields in the 2.0 release even if we don't add any new features in code. I believe the 2.0 release is supposed to include scripts to convert v1.2.3 data and tables to 2.0. That involves quite a few structure changes. While doing that conversion, why not tweak the table structure at the same time to make it more flexible for call numbers? I'm not so sure what we are proposing is going to require many if any new features in code. If those new fields were in place, I think I could do everything I want to get the library I'm supporting up and running on 2.0 by modifying or creating a new set of templates. I simply want to be able to enter and store four or five fields of call number information and then display that call number information to the opac user so they can find the resource on the shelves. I don't want to get too detailed here on the general list, but I've looked at the templates and think I can do both with some simple template changes. But the immediate problem is that I don't have the necessary fields to store my call number information. I have a library that wants to go live when 2.0 is released. I hope we don't have to wait for 2.1. Your suggestion for a wiki page is probably a good idea. If we did that and if everyone that is interested in better support for call numbers could agree on a plan for what fields are needed in the next couple weeks, do you think we could get that included in the 2.0 release (without adding any new features in code)? Rob ----- Original Message ----- From: "Chris Cormack" <chris@katipo.co.nz> Sent: Tuesday, June 17, 2003 1:29 PM Subject: Re: [Koha] More questions - another 2 cents worth
AHhh it all becomes clear :-)
Yep, that makes much more sense. I think ive seen the first new thing for the upcoming 2.1.x tree :-) We are in feature freeze currently heading into the release of 2.0 but as soon as thats stable enough, we can start development on new features.
It might be good to start a page on the wiki where ppl can build a plan for handling the differing call numbers.
Chris
-- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
robweir@alum.drexel.edu wrote:
Thanks for the feedback Chris. I would like to lobby for at least including the new fields in the 2.0 release even if we don't add any new features in code. I believe the 2.0 release is supposed to include scripts to convert v1.2.3 data and tables to 2.0. That involves quite a few structure changes. While doing that conversion, why not tweak the table structure at the same time to make it more flexible for call numbers?
Good news : the upgradedatabase script take care of this, independantly from version change. The problem for 1.2 => 2.0 is that after modifying the DB (that's done by upgradedatabase), you have to create MARC datas from KohaDB If we include LC in version 2.0.1, you will just have to launch upgradedatabase script.
I'm not so sure what we are proposing is going to require many if any new features in code. If those new fields were in place, I think I could do everything I want to get the library I'm supporting up and running on 2.0 by modifying or creating a new set of templates. I simply want to be able to enter and store four or five fields of call number information and then display that call number information to the opac user so they can find the resource on the shelves. I don't want to get too detailed here on the general list, but I've looked at the templates and think I can do both with some simple template changes. But the immediate problem is that I don't have the necessary fields to store my call number information. I have a library that wants to go live when 2.0 is released. I hope we don't have to wait for 2.1.
We won't do it for 2.0.0 We should do it for 2.0.1. There's no need to wait for 2.1/2.2. REMINDER : * 2.0.x will include *improvments*. * 2.2.x will include *new* features. Like serials, of better stat module. what you ask is an improvment for feature partially existing => in 2.0.x tree imho. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (5)
-
baljkas＠mb.sympatico.ca -
Chris Cormack -
paul POULAIN -
rachel＠katipo.co.nz -
robweir＠alum.drexel.edu