Re: [Koha-devel] inflexible field types for call numbers

[Albert P. Calame]

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
address@hidden

----- Original Message ----- 
From: <address@hidden>
To: <address@hidden>
Sent: Friday, June 06, 2003 3:42 PM
Subject: [Koha-devel] inflexible field types for call numbers


> 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
their
> 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
purpose,
> or would it hurt to add a couple field to the biblioitems table? What is
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
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/koha-devel
>