- Koha-devel - lists.koha-community.org

Re: [Koha-devel] Re: [Koha] Re: DDC and LC classification - 2 cents more
by Stephen Hedges 18 Jun '03

18 Jun '03

I thought it would show whatever you put in. If you put in an LC number, that's what you get out. The problem is being able to put an LC number in, right? Stephen Hedges > Yes, any real marc or later record should have > it, but what I was trying to > stress (and yes I am starting to get stressed)! > You have to have koha have the > ability to use that information for those of us > in the upper educational and > scientific community AND NOT HAVE IT SHOWING > DEWEY! > > This must be an easy to change option for the > library involved that should > be selectable at startup/install time. > > The library that is to use the software should > not have to write any scripts, > recode something, or go to any other effort than > to indicate during install > if they wish Dewey or lc. > > Ed! > > > > Subj:[Koha-devel] Re: [Koha] Re: DDC and LC > classification - 2 cents more > > Date:6/17/2003 5:56:21 PM US Mountain Standard > Time > > From:<A > HREF="mailto:albert.p.calame@sympatico.ca">albert. > p.calame(a)sympatico.ca</a> > > To:<A > HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.k > atipo.co.nz</a>, <A HREF="mailto:koha- > devel(a)lists.sourceforge.net">koha- > devel(a)lists.sourceforge.net</a> > > Sent from the Internet > > > > > > > > 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(a)sympatico.ca > > > > > > Original Message ----- > > From: "Stephen Hedges" > <shedges(a)athenscounty.lib.oh.us> > > To: <ABanks(a)buscominc.com> > > Cc: <koha(a)lists.katipo.co.nz>; <koha- > devel(a)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(a)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(a)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(a)lists.katipo.co.nz > > > > > > > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > > > > > > > _______________________________________________ > > > > Koha mailing list > > > > Koha(a)lists.katipo.co.nz > > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > _______________________________________________ > > > Koha mailing list > > > Koha(a)lists.katipo.co.nz > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > ------------------------------------------------ > ------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become > An INetU Hosting Partner. > > Refer Dedicated Servers. We Manage Them. You > Get 10% Monthly Commission! > > INetU Dedicated Managed Hosting > http://www.inetu.net/partner/index.php > > > _______________________________________________ > > Koha-devel mailing list > > > Thanks Ed Sharpe, Archivist for SMECC > > See the Museum's Web Site at > > www.smecc.org > > We are always looking for items to add to the > museum's display and ref. > library > please advise if you have anything we can use. > > mail: > > Coury House / SMECC > 5802 W. Palmaire Ave. > Glendale Az 85301 USA > > 623-435-1522 > > CONFIDENZIALE: Questo messaggio e gli eventuali > allegati sono confidenziali > e riservati. Se vi è stato recapitato per errore > e non siete fra i > destinatari elencati, siete pregati di darne > immediatamente avviso al > mittente. Le informazioni contenute non devono > essere mostrate ad altri, né > utilizzate, memorizzate o copiate in qualsiasi > forma. > > CONFIDENTIAL: This e-mail and any attachments > are confidential and may > contain reserved information. If you are not one > of the named recipients, > please notify the sender immediately. Moreover, > you should not disclose the > contents to any other persons, nor should the > information contained be used > for any purpose or stored or copied in any form. > > >

1 0

Re: [Koha] Re: DDC and LC classification - 2 cents more
by Stephen Hedges 18 Jun '03

18 Jun '03

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(a)sympatico.ca > > > Original Message ----- > From: "Stephen Hedges" > <shedges(a)athenscounty.lib.oh.us> > To: <ABanks(a)buscominc.com> > Cc: <koha(a)lists.katipo.co.nz>; <koha- > devel(a)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(a)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(a)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(a)lists.katipo.co.nz > > > > > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > > > > _______________________________________________ > > > Koha mailing list > > > Koha(a)lists.katipo.co.nz > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > _______________________________________________ > > Koha mailing list > > Koha(a)lists.katipo.co.nz > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Re: DDC and LC classification
by Stephen Hedges 18 Jun '03

18 Jun '03

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(a)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(a)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(a)lists.katipo.co.nz > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

3 2

Re: [Koha-devel] Re: [Koha] Re: DDC and LC classification - 2 cents more
by COURYHOUSE＠aol.com 17 Jun '03

17 Jun '03

Yes, any real marc or later record should have it, but what I was trying to stress (and yes I am starting to get stressed)! You have to have koha have the ability to use that information for those of us in the upper educational and scientific community AND NOT HAVE IT SHOWING DEWEY! This must be an easy to change option for the library involved that should be selectable at startup/install time. The library that is to use the software should not have to write any scripts, recode something, or go to any other effort than to indicate during install if they wish Dewey or lc. Ed! > Subj:[Koha-devel] Re: [Koha] Re: DDC and LC classification - 2 cents more > Date:6/17/2003 5:56:21 PM US Mountain Standard Time > From:<A HREF="mailto:albert.p.calame@sympatico.ca">albert.p.calame(a)sympatico.ca</A> > To:<A HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A>, <A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel(a)lists.sourceforge.net</A> > Sent from the Internet > > > > 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(a)sympatico.ca > > > Original Message ----- > From: "Stephen Hedges" <shedges(a)athenscounty.lib.oh.us> > To: <ABanks(a)buscominc.com> > Cc: <koha(a)lists.katipo.co.nz>; <koha-devel(a)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(a)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(a)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(a)lists.katipo.co.nz > > > > > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > > > _______________________________________________ > > > Koha mailing list > > > Koha(a)lists.katipo.co.nz > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > _______________________________________________ > > Koha mailing list > > Koha(a)lists.katipo.co.nz > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Koha-devel mailing list Thanks Ed Sharpe, Archivist for SMECC See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library please advise if you have anything we can use. mail: Coury House / SMECC 5802 W. Palmaire Ave. Glendale Az 85301 USA 623-435-1522 CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono confidenziali e riservati. Se vi è stato recapitato per errore e non siete fra i destinatari elencati, siete pregati di darne immediatamente avviso al mittente. Le informazioni contenute non devono essere mostrate ad altri, né utilizzate, memorizzate o copiate in qualsiasi forma. CONFIDENTIAL: This e-mail and any attachments are confidential and may contain reserved information. If you are not one of the named recipients, please notify the sender immediately. Moreover, you should not disclose the contents to any other persons, nor should the information contained be used for any purpose or stored or copied in any form.

1 0

Re: [Koha-devel] 2.0 release meeting
by COURYHOUSE＠aol.com 17 Jun '03

17 Jun '03

JUST BE SURE THE lc CALL NUMBER WITH LINES FOR IT IS DISCUSSED AND IMPLEMENTED PLEASEEEEEEEEEEEEEEE! ED SHARPE > Subj: [Koha-devel] 2.0 release meeting > Date: 6/17/2003 3:44:48 PM US Mountain Standard Time > From: <A HREF="mailto:pate@eylerfamily.org">pate(a)eylerfamily.org</A> > To: <A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel(a)lists.sourceforge.net</A>, <A HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A> > Sent from the Internet > > > > Hello everyone, > With a 2.0.0 release rapidly approaching, and a bunch of bugs needing to > be found, reported, prioritized, and fixed, we're going to institute a > weekly irc meeting to help handle the load. > > We'll meet every Wednesday at 1900 UTC in the #koha channel at > irc.katipo.co.nz -- Anyone is welcome to attend, please bring your bug > reports. If you can't make it this week (short notice, I know), please > drop in to any of the meetings you can make. > > (Here are a couple of conversions follow) > UTC France Seattle New Zealand > Wed 19:00 Wed 21:00 Wed 12:00 Thu 07:00 > > > (Please feel free to translate and/or forward this message to > other mailing lists as appropriate.) > > -pate > > Pat Eyler > Kaitiaki/manager migrant Linux sys admin > the Koha project ruby, shell, and perl geek > http://www.koha.org http://pate.eylerfamily.org > >

1 0

Re: [Koha] More questions - another 2 cents worth
by ABanks＠buscominc.com 17 Jun '03

17 Jun '03

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(a)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/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 > 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(a)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(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Templates internationalisation
by Jerome Vizcaino 14 Jun '03

14 Jun '03

Hi This mail contains a modification we made to make Koha template translation a lot more easier. Here is the idea : We created a table in Koha named opac_text containing three field - id : the identifier of the text - lang : corresponding language - label : the text to be used Using the Label.pm, we use a gettexttemplate to get the label corresponding to the requested id. This way, with only one .tmpl file, unlimited languages are available without any changes in the .tmpl file. To prove this trick is usable and not so hard to implement we've attached 4 files : Label.pm, opac-detail.pl, opac-detail.tmpl and opac_text.sql. Here is how to test it : 1 - Create the table containing the labels : mysql -u root -p < opac_text.sql 2 - Copy the Label.pm in the C4 module directory 3 - Copy opac-detail.pl to the opac/ cgi-bin directory 4 - Copy opac-detail.tmpl to the opac/htdocs/opac-tmpl/default/en directory. Make a link to this file in the opac/htdocs/opac-tmpl/default/fr so that no physical duplication is needed. This way changing the opaclanguages preference will still use the generic template. Now try and search a book and click on one of the result to show the details. If you're using either 'en' or 'fr' opaclanguages option. Changing the preference will change the language in the display. For sure, it requires a little more cpu to display the page but with a PII 350 (our test machine) no noticable slow down was reported. Using a system like the authorised value builder, creation of new languages would be made easier. We need some feedback on this please :) Thanks Jerome and Michel

3 4

inflexible field types for call numbers
by robweir＠alum.drexel.edu 12 Jun '03

12 Jun '03

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

2 1

Perl variables appearing in acquisitions page
by Buchan Milne 11 Jun '03

11 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We are testing koha for internal use in tracking publications in our company. The other admin (who is out for the day, and on holiday for a week from tomorrow) set koha up, so I'm left to see if I can solve the admin staff's problems. I am not too familiar with how koha works, but the same behaviour appears on the demo setup: http://hlt.katipo.co.nz/cgi-bin/koha/acqui.simple/additem-nomarc.pl?biblion… You will see the drop-down boxes aren't filled correctly. I am not too familiar with HTML::Template, so haven't been able to track down the reason for this. Note, we don't intend to use MARC records. Any hints on how to go about fixing this? Also, we have migrated all authentication systems to use LDAP (including windows machines via Samba with LDAP support), so we would also be interested in support for LDAP authentication (preferably using a normal unix username instead of a card number). We are running 1.9.3 on apache 1.3.22 (with patches of course) with MySQL 3.23.41 and Perl 5.6.1 Regards, Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+5y6vrJK6UGDSBKcRAjl4AJ46zvOHDiWtT75ERmGOYJwFTcKwpACdFvkd uhuF5pVHgCD2uPpeQoBBoVc= =/gq0 -----END PGP SIGNATURE----- ****************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to info(a)cae.co.za for a copy. ******************************************************************

1 0

2.0 release meeting
by Pat Eyler 10 Jun '03

10 Jun '03

Hello everyone, With a 2.0.0 release rapidly approaching, and a bunch of bugs needing to be found, reported, prioritized, and fixed, we're going to institute a weekly irc meeting to help handle the load. We'll meet every Wednesday at 1900 UTC in the #koha channel at irc.katipo.co.nz -- Anyone is welcome to attend, please bring your bug reports. If you can't make it this week (short notice, I know), please drop in to any of the meetings you can make. (Here are a couple of conversions follow) UTC France Seattle New Zealand Wed 19:00 Wed 21:00 Wed 12:00 Thu 07:00 (Please feel free to translate and/or forward this message to other mailing lists as appropriate.) -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

1 0