[Koha] Re: DDC and LC classification - 2 cents more
Stephen Hedges
shedges at athenscounty.lib.oh.us
Wed Jun 18 19:49:05 NZST 2003
Al is exactly right -- MARC has already solved this entire issue of breaking
down/storing call numbers, etc. For MARC21, the 852 tag subfields $h, $i, $k,
$m, and $t cover this. (I think UNIMARC's 852 tag is similar, but I don't
know.)
But Koha still has a problem, because it maps MARC data to the old Koha non-
MARC database, and most (all?) of the templates work from that old Koha
database. So a library needs to be able to map each of those five subfields to
a unique column in a Koha table. And the current tables can't handle that.
And then there's the whole issue of repeatable subfields . . .
Stephen
> 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.ht
> m
> >
> > 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
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
More information about the Koha
mailing list