[Koha] Re: DDC and LC classification - 2 cents more

[Albert P. Calame]

Hi All!
    We may be missing the point with this discussion. Firstly, while DDC
uses mostly a single Classification Number that could fit on a single line
(There are a few cases, as with Shakespeare, where an additional line with a
special additional code is used to bring out a specific play), a Call Number
is not equal to a Classification Number. The Call Number on a book or other
item is intended to assist in the location of items where they have been
stored (typically books on shelves), however the Classification Number is
just a part of the whole Call Number.  As Steven mentions below, most
libraries add prefixes to indicate shelving locations and add an additional
line to indicate the Author or Biographee.  The Dewey Number can vary in
length from 2 to probably 20 characters, and in such cases, often the number
will be split between more than one line (average spine labels are only
about 10 characters wide).

    In the case of LC Classification, Call numbers usually have 4 lines -
two for Classification, one for Date (the three Steven has below) and most
often a line for Cutter Number (a code for Author similar in function to the
Dewey Author line).  Here, too, there may be a prefix to make up the entire
Call Number.

    In both cases, the classification number tries to group materials on
like subjects together so that they are easier to locate.

    I _don't_ see, however, the need within koha to give the older non-MARC
data structure the additional structures needed to store LC Call Numbers,
when any of the MARC structures can do so very well - indeed the required
subfields are already in place. I would be surprised if a library that is
using LC Classification would want to establish their database in other than
MARC structure, especially when we realize that the source of records that
the typical academic and scientific libraries that use LC would use to build
their catalogues are most likely to be in MARC structure to start with. Why
convert the data to a new structure when koha will store it in the original
structure to start with?

    I understand that some librarians may not particularly care to use MARC,
I used to be one of them! But it is the de facto standard for the exchange
of bibliographic data. It does have all the fields and subfields already
defined to do the job for us. It has built-in flexibility to meet any
special needs we may have. It doesn't take too long to come to appreciate
that the MARC21 structure does let you do whatever you need to. It only
requires that you study a bit to get used to it at first. Non cataloguers
likely would think I'm a bit batty for even wanting to!;-)  More
importantly, however, why re-invent the wheel?

    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 (maybe
20) to account for even the longest Dewey likely to be used with 12 places
after the decimal , or possibly for a complete surname which is sometimes
entered in the case of a biography [some names could well exceed the 16
chars]). {MARC structure gives a maximum field length for any field of 9999
characters, so each subfield could be greater than the minimums I mention
above .}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.


    Let's make sure, however, that when it comes time to display or print
the Call Numbers, whether with LC or DDC, that we have stored in koha, that
we can do so properly, and would be able to actually print new spine labels
for books or other items.
This would be a better use of programming time, imho, than to add additional
structures to the non-MARC structured database in koha for LC users.

    That's my 2 cents worth!

Regards,
Al Calame

Library Automation Consultant,
Librarian-at-Large,
Albert P. Calame Consulting
Montreal, Québec, Canada

514-745-3424
albert.p.calame at sympatico.ca


 Original Message ----- 
From: "Stephen Hedges" <shedges at athenscounty.lib.oh.us>
To: <ABanks at buscominc.com>
Cc: <koha at lists.katipo.co.nz>; <koha-devel at lists.sourceforge.net>
Sent: Tuesday, June 17, 2003 6:22 PM
Subject: [Koha] Re: DDC and LC classification


> For starters, here's a good place to learn how Dewey Decimal
Classification
> (DDC) works:
>
> http://www.oclc.org/oclc/fp/about/about_the_ddc.htm
>
> If you look at this URL and the ones Rob sent, it looks like DDC always
fits on
> one line, while LC can run to as many as five lines.  That's true in a
> theoretical world.  In the real world, libraries muck around and add other
> stuff, to help the people who have to stick the books back on the shelves.
>
> Here's an example.  The copy of The Chicago Manual of Style I have beside
me
> has the Library of Congress Cataloguing-in-Publication (CIP) data printed
> inside the fly leaf.  It says that the "official" classifications are as
> follows:
>
> LC would be -
>  Z253
>  U69
>  1993
>
> DDC would be -
>  808  or 808.027  or 808.0270973 if I'm really picky.
>
> Looks like 3 lines for LC and 1 line for DDC.
>
> But in practice, it's hard for humans to keep a long string of numbers
straight
> and in order when re-shelving books, so most libraries that use DDC do
what my
> library does -- add an extra line with the first two letters of the title
or
> the author's name under a _short_ Dewey number.  So the spine label on
this
> particular book reads:
>  808
>  Ch
> instead of
>  808.0270973
>
> Now it gets really fun!  Many libraries also add stuff _before_ the Dewey
> number, like AB for audiobooks or YA for young adult or J for juvenile or
> junior.  (LC libraries sometimes do this, too.)  Yeah, they're really
> categories and shouldn't be part of the call number.  But again, they help
> humans find, retrieve, and replace stuff on library shelves.  Practice
> supercedes theory once again!
>
> But to get to the point, five lines should be quite enough for most
purposes,
> for either LC or DDC.  I'm sure someone will disagree, but any library
that
> thinks it has to have six lines probably needs some discipline!
>
> Stephen Hedges
> (Nelsonville Public Library)
>
> > I've been working on SQL phrasebooks to enable
> > multiple backend DB support.  I would be happy to
> > help with changing these fields around.
> >
> > Since my knowledge of library science is pretty
> > much limited to what I've learned off of this
> > list, could someone step up to the plate to do
> > some research on the type and number of fields
> > needed?
> >
> > ----- Original Message -----
> > From: Chris Cormack <chris at katipo.co.nz>
> > Date: Tuesday, June 17, 2003 1:29 pm
> > Subject: Re: [Koha] More questions - another 2
> > cents worth
> >
> > > 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/understanding
> > lccn/webcall2.html or
> > >
> > http://www.hcc.hawaii.edu/education/hcc/library/ca
> > llno.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
> > > catalogingsystems 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:
> > > inflexiblefield types for call numbers).
> > >
> > > My recommendation would be that we survey as
> > many knowledgeable
> > > librariansas 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
> > > programmerscould suggest existing fields that
> > can be used). I
> > > think if there were four
> > > or five flexible fields for storing call number
> > information, then
> > > indeedkoha could be adapted to almost any
> > cataloging system by
> > > reworking the
> > > templates.
> > >
> > > Rob
> > >
> > > ----- Original Message ----- 
> > > From: "Chris Cormack" <chris at 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.
> > >
> > >
> > _______________________________________________
> > > Koha mailing list
> > > Koha at lists.katipo.co.nz
> > >
> > http://lists.katipo.co.nz/mailman/listinfo/koha
> > >
> >
> > _______________________________________________
> > Koha mailing list
> > Koha at lists.katipo.co.nz
> > http://lists.katipo.co.nz/mailman/listinfo/koha
> >
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha