Hi all,
I'd like to address an issue that I think could limit Koha's acceptance as a viable solution in certain parts of the world - specifically the current database fields available for storing call number information. Since call numbers are so vital for a library and because there are so many different systems for assigning call numbers, I think it would be to our advantage to to make Koha as flexible as possible to work as many call number systems as possible.
I think what I'm proposing might only involve changing a couple field types or adding a field or two. Since we need to write conversion scripts to move data from V1.2.3 to V2.0, wouldn't this be the best time to tweak the database fields?
The issue I'm confronting is that almost every library I'm familiar with here in the USA uses call number labels on the spines of their books with four or even sometimes five lines of call number information. The second line is usually all numbers, but not always. So basically there is a need to store four or five fields worth of alpha-numeric call number information with each field containing up to 8 or 10 characters. In looking at the current fields available for call numbers in the biblioitems table, I find several are not flexible enough to store this kind of data because of
field type or length. Specifically, itemtype is varchar(4), dewey is double(8,6), subclass is char(3), and publicationyear is smallint(6). So none of those fields is suitable for storing up 8 to 10 digits of alpha-numeric call number information. Did I miss some other possible fields, or what is a library with four fields of call number information supposed to do?
Ideally, I think Koha should have five fields possibly of type varchar(10) available for storing call number information. If dewey and subclass were converted to varchar, that would provide two. Would making that conversion break anything in the existing code? (I do see a number of FIXME comments already in Search.pm about dewey being a string and not a floating point number).
Are there any other existing fields that could be adapted for this
or would it hurt to add a couple field to the biblioitems table? What is
Hi All! I'm not sure I understand all the programming stuff about the types of fields, but I have to concur that the data should be stored in such a way so that the call numbers can be entered in such a way as to reproduce the Call Number Label on the spines of the books. The MARC21 structure provides for this by having several subfields devoted to that specific information. As long as the fields can contain enough data (I suggest 16 characters to account for even the longest Dewey likely to be used with 12 places after the decimal - a string not floating point as mentioned, or possibly for a complete surname which is sometimes entered in the case of a biography [some names could well exceed the 16 chars]). Those subfields are: Tag 852 with subfields - $h - Classification part (NR) (Dewey or LC Classification numbers, such Alpha Classification as E for Easy, B for Biography,etc.) $i - Item part (R) (Used for author letters, cutter numbers, or sometimes biographees last names) $k - Call number prefix (R) (Like REF for reference collections, etc) $m - Call number suffix (R) $t - Copy number (NR) [This information comes from the MARC Standards page at the Library of Congress Web page with my comments in parentheses after the designation of repeatable or non repeatable] The MARC structure, with subfields k, i, and m as repeatable does take care of places to store the Call Numbers appropriately. The only problem I can see is that the biblioitems table needs to be able to store the information in the same way, and koha needs to be able to display the repeatable subfields appropriately also. Display order would normally be: k, h, i, m, t. Display has always been a problem with fields that may be longer that would fit on a single line of a label, hence the addition of break characters that you may see sometimes as apostrophes in the middle of long Dewey Class numbers. I hope this helps to clarify the problem and results in programming that makes the display and storage of Call Numbers in koha work in a way that will suit all levels of users. Regards, Al Calame Consultant, Librarian-at-Large, Albert P. Calame Consulting Montreal, Québec, Canada 514-745-3424 albert.p.calame@sympatico.ca ----- Original Message ----- From: <robweir@alum.drexel.edu> To: <koha-devel@lists.sourceforge.net> Sent: Friday, June 06, 2003 3:42 PM Subject: [Koha-devel] inflexible field types for call numbers their purpose, the
classification field for? Once these fields are available for storing the data, individual libraries could develope their own templates for displaying the call number information in a format that matches the spine labels on their books.
I would be interested to hear if anyone else has confronted this problem and how they solved it. What is Nelsonville Library doing for their call numbers? What call number systems are used in other parts of the world and would this idea work for them?
Thanks, Rob
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel