- Koha - lists.katipo.co.nz

MARC tag structure problem, Dewey problems & Possible to create items when importing MARC?
by Aren Olson 13 Sep '06

13 Sep '06

I am helping a public library switch to koha, and have a few problems that have come up while importing the old data. First, on the "MARC Check" page, It says *item fields* ALL items fields MUST : be mapped to the same tag, and they must all be in the 10 (items) tab *Item tag* There is more than 1 MARC tag related to items tab (10) : 852,952, This is correct, the previous ILS's MARC setup puts some item data on each tag. Is it safe to leave it like this? Secondly, some of the old items had their dewey number in the "Material Type" section. This results in koha putting each of these items into its own type, eg. "910", or "E567". Is there any way to tell koha these items belong to a particular type? Thirdly, is there any way to have koha automatically create items from a MARC import? The records import, but I have to manually create an item for each record before I can use it. This is impractical, since there are thousands of records. I am using koha 2.2.5 on Ubuntu Linux. Thanks, Aren Olson reacocard(a)gmail.com -- "Whoever said sunshine brings happiness has never danced in the rain." - K. Jackson Ubuntu Linux - www.ubuntu.com

2 1

marc_word table and koha 2.2 performance on updates
by Victor Ashik 13 Sep '06

13 Sep '06

Hello, I am trying to use 2.2.6RC2 with MySQL 4.1 on Debian Stable to store catalog with mix of russian and english books in UTF-8. I wrote a perl script to import books from CSV file. Performance of import slows down after importing 500-600 books, because size of marc_word becomes huge. Currently I have: mysql> select count(*) from biblio; +----------+ | count(*) | +----------+ | 745 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from marc_word; +----------+ | count(*) | +----------+ | 6747764 | +----------+ 1 row in set (0.00 sec) There are a lot of words in marc_word table that looks empty. Search is working only for english names and does not works for Russian, although I can see russian letters in correct UTF-8 inside mysql and I have set up mysql and apache to work with UTF-8; CSV file I use does not have a lot of empty fields. Why so many rows in marc_word although I use koha-2.2.6RC2? Please help. -- Regards, Victor Ashik P.S.: Here is the script: #!/usr/bin/perl use MARC::Record; use C4::Context; use C4::Biblio; use C4::AuthoritiesMarc; my $dbh = C4::Context->dbh; my $newRecord = MARC::Record->new(); # FIXME: I do not know how to calculate record size now so use fixed one $newRecord->leader('00903pam 2200265 a 4500'); #$record->set_leader_lengths(); # parse CSV fields while (<>) { my $text = $_; my @new = (); push(@new, $+) while $text =~ m{ "([^\"\\]*(?:\\.[^\"\\]*)*)",? |([^,]+),? |, }gx; push (@new, undef) if substr($text,-1,1) eq ','; # System Control Number my $newField = MARC::Field->new( '035','','', 'a' => $new[0], ); $newRecord->insert_fields_ordered($newField); # Author $newField = MARC::Field->new( '100','','', 'a' => $new[1], ); $newRecord->insert_fields_ordered($newField); # Organization $newField = MARC::Field->new( '110','','', 'a' => $new[2], ); $newRecord->insert_fields_ordered($newField); #my $newField = MARC::Field->new( # '440a','','', # 'a' => $new[3], #); #$newRecord->insert_fields_ordered($newField); #my $newField = MARC::Field->new( # '440n','','', # 'a' => $new[4], #); # I found that next line was not commented out while writing this post #$newRecord->insert_fields_ordered($newField); # Title $newField = MARC::Field->new( '245','','', 'a' => $new[5], ); $newRecord->insert_fields_ordered($newField); # Place of publication $newField = MARC::Field->new( '260','','', 'a' => $new[7], ); $newRecord->insert_fields_ordered($newField); # Name of publisher $newField = MARC::Field->new( '260','','', 'b' => $new[8], ); $newRecord->insert_fields_ordered($newField); # Date of publication $newField = MARC::Field->new( '260','','', 'c' => $new[9], ); $newRecord->insert_fields_ordered($newField); # General subdivision $newField = MARC::Field->new( '655','','', 'x' => $new[10], ); $newRecord->insert_fields_ordered($newField); print $newRecord->as_formatted(); my ($bibid,$oldbibnum,$oldbibitemnum) = NEWnewbiblio($dbh,$newRecord,''); }

1 0

Making the user log in
by Greg Vickers 13 Sep '06

13 Sep '06

Hi all, The Koha installation for Alliance Francaise (http://library.afbrisbane.com) is coming along nicely. The library wish to change the behavior of Koha once you have done a successful search on the library catalog. For example: Visit the library site, search for something that returns a hit ('fred' works), follow the link to see the detail of one of the entries. At this screen, the 'Request' link (to opac-reserve.pl) makes the user login, but the links 'Add to shelf' (opac-addbookbybiblionumber.pl) and 'Add to basket' (a javascript link) do not make the user log in. The library want these other two links to make the browser log in. Will there be any problems adding this functionality to these two links? (i.e. adapting the code in the 'Request' link!) Greg

1 0

Re: [Koha] Getting books into the database
by Steven F.Baljkas 13 Sep '06

13 Sep '06

Thursday, August 24, 2006 17:49 CDT Thaetviking, Alex has already provided a good answer to your questions, so this rushed e-mail will only serve as an addendum for now. Please note, I am willing to help out with MARC record data issues, and converting from Follett data records falls into that broad category. I don't know what the shape of your data is, but I can help get you started at least in converting it into proper MARC21. It has been some time, but I do vaguely recall Follett being able to export delimited text. If that is correct, then you are in luck, because there is an excellent free utility called MARCEdit, developed by Terry Reese and available off of the Library of Congress MARC Records, Services and Tools page at URL <http://www.loc.gov/marc/marctools.html> . This excellent program can convert delimited text into valid MARC21 records. (And please people: could we start calling it by its proper name, MARC21? USMARC records, CANMARC, etc. persist but all new records created by the higher authorities (at the least) are now MARC21 and the rules governing record validity are MARC21. Sorry. Back off the soapbox now ...) The MARCEdit editor also provides a very neat tagged record format which makes it easy to correct and add to records before converting the text into MARC. If you do end up losing your barcode data, manual re-insertion of the barcodes would likely be easiest to do using the MARCEdit editor. When you are done editing and have automagically converted the records using MARCEdit, you can then use Koha's bulkmarkimport script to upload the whole lot. Thaetviking, if you are unsure about the structure of what Follett is exporting (I didn't understand your comment about not knowing exactly where the DB is), feel free to send me a small sample off listserv and I'll take a look at it for you by the end of the weekend. That's the best I can do right now with circumstances here as they are. On to the rest ... Have no idea what CDDB is. Always best to define acronyms and abbreviations that might not be clear to all. At least that way, we all may learn something. As for using barcodes as identifiers, there are a few reasons in cataloguing that make this unwise. For one thing, barcodes get lost, defaced, destroyed, and replaced. For another, not all systems would tolerate using barcodes in the way I think you mean, and as wonderful as Koha is, one should always free up options for future migrations rather than limit them. In any case, if you want a unique identifier, the record number (field 001) can serve as a unique key for the metadata. Again: get back to me with a Follett sample if you are unsure; and, I am more than willing to help out to the extent that I can long-distance with your MARC record conversion (I just can't do it all for you as I have 3 volunteer Koha MARC record projects on the go now). Hope that this has helped a bit. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada "At 13 I knew everything. Senility set in some time after." -- Harvey Fierstein, _Torch Song Trilogy_ ============================================================ From: thaetviking <c_middleman(a)yahoo.com> Date: 2006/08/24 Thu AM 08:26:29 CDT To: koha(a)lists.katipo.co.nz Subject: [Koha] Getting books into the database I have been given the joy of redoing everything in our library because of some ineptness. I need quick answers if possible. We are running Follett and the novell server died and I was given the task of dealing with this after the person who ran it was fired. I would like to move to open source but was wondering can you convert the tables for follet? Also can you scan the barcode on a book and have it up the information on the web kind of like CDDB? Since we already have barcodes made for each book can we use the pre-generated ones as their identifier? I really appreciate any help. I am not sure were exactley the DB is so the last two questions may be more to the meat of what I need? -- View this message in context: http://www.nabble.com/Getting-books-into-the-database-tf2158615.html#a59638… Sent from the Koha - Discuss forum at Nabble.com. _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ============================================================

2 1

Emilda and Koha: how to choose between them?
by Paul Gear 12 Sep '06

12 Sep '06

Hi folks, (Apologies in advance for the HTML mail, but i couldn't find a better way to represent the table below...) I've been evaluating implementing a couple of small libraries (my church and home, both around 1000 volumes) on Emilda and Koha, and i'd be interested in comments from people about their relative strengths and weaknesses. I'm coming from the perspective of a K-12 school IT manager with a Unix background. I don't know much about library cataloguing (although i'm learning), and MARC is almost incomprehensible to me (as it is to all of the librarians i know). :-) I'd really love to convert my school (about 80,000 resources) from a proprietary system to Koha, and i'm using these libraries as guinea pigs. However, my call is not final at school: there are a number of other staff to convince. The merits of free software would have to be pretty strong for us to only save around AU$1000/year (the maintenance contract on our existing library system), not to mention that there's no local phone support. Neither Koha nor Emilda seems to have the features to challenge the more school-oriented library systems yet. Here are my perceptions so far: Product Pros Cons Emilda * Very easy to install on Debian * Z39.50 cataloguing is easy to set up and robust * Simple interface * Easy to hack on (PHP-based) * Exposes a lot of MARC & Yaz; adding search and cataloguing fields requires advanced skills * Developer/user communities not so active (user mailing list about 1/10th the traffic of Koha's) * Requires login to self-loan and -return Koha * Nice features in interface (e.g. cover images) * Pretty (the suggested demo sites look awesome!) * Seems to have quite an active developer and user community * Install not so simple - no Debian package; requires messing about with CPAN * Requires separate Z39.50 daemon that, when last i used it (not the current version), broke easily and frequently * Interface is moderately complex (a moderate amount of MARC) * I hate Perl (i know it to a reasonable level of competency, and write scripts in it regularly - i just hate looking at it). Can anyone comment on whether: * Koha has pros for Emilda's cons? (Self-loan and return seems to be one.) * Koha's cons have improved since i last looked at it? Are there any other considerations that i should be looking at? Low maintenance is a priority for me - after i've implemented the systems, i won't have a lot of time to spend on them. Both products seem to fit the bill in this respect, although i haven't tried to restore one from backup yet. ;-) Thanks for listening, Paul <http://paulgear.webhop.net> -- Did you know? Microsoft Internet Explorer and Outlook have a poor track record for security <http://www.kb.cert.org/vuls/id/713878>. Why not try one of the more secure alternatives from <http://mozilla.org>?

5 6

Your template
by BWS Johnson 12 Sep '06

12 Sep '06

Salvete! I don't think I've asked this yet, but it's past time I did. What template is everyone using with Koha? I've been getting the distinct impression from some questions that I've fielded that it might be time to switch the template my documentation uses. Cheers, Brooke @ Hinsdale MA

2 1

Re: [Koha] MARC structures
by Lenora Oftedahl 12 Sep '06

12 Sep '06

Hi. I'm currently running 2.2.5, so I'll check the structure in CVS. Thanx. Lenora >>> "Thomas Dukleth" <kohalist(a)agogme.com> 9/12/2006 8:45:29 AM >>> Lenora, Before you do too much redundant work, you should look at what is available in Koha CVS. There is a very comprehensive Koha standard MARC 21 bibliographic framework in CVS. 1. KOHA 2.2.6 OR GREATER. I am not certain which possible upgrade path you would likely be using. There will be multiple paths soon. http://download.savannah.nongnu.org/releases/koha/koha-2.2.6RC2.tar.gz may be the version closest to stable release and certainly the easiest to install. You need at least a 2.2.6 testing version ion or a CVS checkout install for CVS branch rel_2_2, dev_week, or rel_3_0 to properly use the comprehensive MARC 21 bibliographic framework in CVS. There are instructions for updating release 2.2.5 to the rel_2_2 CVS version. Joshua Ferraro. Pierrick Le Gall. Updating Koha. 2006. http://www.kohadocs.org/Updating_Koha.html . In Koha Documentation. http://www.kohadocs.org/ . I think that the bugs remaining in rel_2_2 are far fewer and certainly less serious than bugs in 2.2.5. 1.1. UTF-8 ENCODING CONVERSION. You also need to upgrade your records and database to UTF-8 encoding for Koha versions 2.2.6 or later. If you have valid MARC 21 records and you are not yet actively using Koha, just use the latest bulkmarcimport.pl file for the release you need from http://cvs.savannah.nongnu.org/viewcvs/koha/misc/migration_tools/bulkmarcim… . Currently, the latest verson for rel_2_2 is http://cvs.savannah.nongnu.org/viewcvs/*checkout*/koha/misc/migration_tools… . You would need to reimport your records with the purge option to replace the record set you have been testing. If you have a working installation, invalid encodings in your record leaders, or UNIMARC records; you many need professional assistance correcting the encoding of your records in place. See http://www.koha.org/support/pay.html . Other changes are needed, including database changes to support UTF-8. See detailed information about changes. Joshua Ferraro. Encoding and character sets in Koha. http://wiki.koha.org/doku.php?id=encodingscratchpad. In Koha developer wiki. 2. MARC21_STANDARD_BIB_FRAMEWORK.SQL. You would then be able to use the latest version of marc21_standard_bib_framework.sql found at http://cvs.savannah.nongnu.org/viewcvs/koha/misc/marc21_standard_bib_framew… . Currently, the latest version is http://cvs.savannah.nongnu.org/viewcvs/koha/misc/marc21_standard_bib_framew… . marc21_standard_bib_framework.sql is an SQL file meant to be imported by MySQL to install in a existing installation of Koha. Importation instructions are included file comments. If you have an existing installation, upgrading Koha alone will not upgrade your bibliographic framework. You need to import this SQL file. However, the file will not function correctly for version 2.2.5 or earlier. This is a comprehensive MARC 21 bibliographic framework for all common current and historic uses of MARC 21 / USMARC ? CANMARC fields and subfields. The file is about three times the size of the default MARC 21 framework present in 2.2.5. Without such a comprehensive framework and Koha 2.2.6 or later code, you risk losing data every time you edit your bibliographic records within Koha for any fields/subfields in your data not present in your bibliographic framework. Legacy Koha bibliographic frameworks are very incomplete. If you are worried about this in releases of Koha prior to 2.2.6, then use an external record editor; or upgrade both Koha and the Koha bibliographic framework. Always keep a safe backup of your records no matter what software you are using. 2.1. COMPLETENESS. The CVS MARC 21 framework has some elements of incompleteness from lack of funding for the time needed to finish 'see also' values for good indexing of all fields and much of the work has not been double checked for errors. However, it is in use at several libraries without reported problems. Comments in the SQL file include a brief statement of the issues. I know the see also support is incomplete and there are otherwise bound to be some errors in well over 4,000 lines of SQL statements. I suspect missing fields and subfields which could lead to data loss are very unlikely to be major and might no longer exist after the last one I spotted. I would be very happy to finish the work and assure that everything had been double checked if I had funding for the week and a half or so needed to finish and verify the default. Anyone is free to finish that work and I will have to myself even in the absence of funding at some unknown future point when I need it for my own purposes. Related plugins to aid editing MARC 21 fixed fields in the Koha record editor only support books at the present time but you can add correct values manually for other material without using the plugins. Adding additional plugins for other record types, and bibliographic levels apart from books is rather minor work but still takes a little time. There is also one custom non-standard modification with frameworks for 6 simple record types and 3 bibliographic levels at http://cvs.savannah.nongnu.org/viewcvs/koha/misc/asmp_marc21_bib_framework.… . Again, despite more specific framework support for different record types and levels in the Koha record editor, there is not yet fixed field record editor plugin support for those additional record types and levels. The choices of which fields are collapsed by default is a custom request for the ASMP framework set and does not conform to what I have found least inefficient. 2.2. OCLC SPECIFIC FIELDS?SUBFIELDS. Populated OCLC specific fields and subfields will appear in the record editor for versions 2.2.6 and later if the SQL file has been applied. OCLC specific fields which are not holdings specific will appear in the OPAC MARC view for the CVS framework default. You would need to change the new subfield hidden values for the OCLC specific fields/subfields to have them appear by default for the record editor even if unpopulated.. In CVS versions of Koha, there is a list of the meanings of the new hidden values for subfields in the help file for the subfields editing part of the bibliographic framework editor. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Mon, September 11, 2006 8:37 pm, Lenora Oftedahl wrote: > Ok. I'm working on changes to the default MARC fields. I'm trying to get > the MARC fields consistent with OCLC-MARC. Before I get too far, how much > of this work will need to be duplicated when we upgrade to the next stable > release? > > Is there a way to export the structure so that others can use it? > > I'd like to include this information in the cataloging section of the Koha > documentation, which I'm currently working on. > > Thanx. > > > -- > *************************************** > Lenora A. Oftedahl, MLS MEPM > StreamNet Regional Librarian > Columbia River Inter-Tribal Fish Commission > 729 NE Oregon St, Ste 190 > Portland, OR 97232 > 503-736-3581 / ARIEL: 207.173.155.8 > 503-731-1260 FAX > OFTL(a)critfc.org http://www.fishlib.org > ************************************* > "One by one, the penguins are stealing my sanity" > ************************************** > "Don't worry about the world coming to an end today. It's already tomorrow > in Australia." > --(Charles Schultz) > ************************************** > "The problem with adults is that they are contaminated by experience." > --Kumi Naidoo, General Secretary and CEO of CIVICUS > ************************************** > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

MARC structures
by Lenora Oftedahl 12 Sep '06

12 Sep '06

Ok. I'm working on changes to the default MARC fields. I'm trying to get the MARC fields consistent with OCLC-MARC. Before I get too far, how much of this work will need to be duplicated when we upgrade to the next stable release? Is there a way to export the structure so that others can use it? I'd like to include this information in the cataloging section of the Koha documentation, which I'm currently working on. Thanx. -- *************************************** Lenora A. Oftedahl, MLS MEPM StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission 729 NE Oregon St, Ste 190 Portland, OR 97232 503-736-3581 / ARIEL: 207.173.155.8 503-731-1260 FAX OFTL(a)critfc.org http://www.fishlib.org ************************************* "One by one, the penguins are stealing my sanity" ************************************** "Don't worry about the world coming to an end today. It's already tomorrow in Australia." --(Charles Schultz) ************************************** "The problem with adults is that they are contaminated by experience." --Kumi Naidoo, General Secretary and CEO of CIVICUS **************************************

3 2

Re: [Koha] Borrowers vs Branches vs Circulation...
by BWS Johnson 12 Sep '06

12 Sep '06

Salvete! >- a common book database for all branches, WITH proper restrictions >(no modifications, circulation etc. of items from other branch); >- a common borrower database for all branches, but I need .... >- ... ability to assign a borrower to one, two, three or all branches >with respectable issue rules... >- ... and respectable membership policies, which actually narrows to >enrollment period and enrollment fee... >- ... with fines / payments COMMON to all branches a borrower belongs >to. I mean: acount suspended in one branch - automatically suspended >in all and so on. If someone gets time to add these, great. A lot of these resemble what I would consider to be a consortial package. Please keep in mind that effectively you aren't asking for a normal public library setup at all here, you're asking for a normal setup for _multiple_ public libraries (or multiple libraries of different types). Now, I can only imagine that this is a lot of programming for someone (or more likely, several someones.) In short, you're asking for a lot right now. It goes back to good, fast and cheap. You can have 2. I'm willing to wait, because I'm on the good and cheap plan>:). That being said, I'm starting to hear more rumbles from the library community to the effect of "Gee, we wish that we can use Koha for our consortium" or "Gee, it would be neat if a bunch of libraries could get together and use Koha, but we want to retain our individual policies in regards to borrowers and due dates, et cetera." So, if some very, very, very charitable developer out there happened to eventually put this on the road map (or better if it's there and worded differently or I'm too dumb to have noticed put it on the chopping block) that would be splendid. Also splendid would be to assign these features an amount in US dollars in terms of development costs, just in case someone with a big bag of money happens to wish to make them appear out of thin air for folks that are on the fast and good plan. Cheers, Brooke @ Hinsdale MA

2 1

Koha on windows
by Venita Glasfurd 12 Sep '06

12 Sep '06

Hi, I have installed Koha2.2.4 on Windows and am testing it for usage for a private library. My problem is that the koha installer expects the mysql and perl to reside in a particular folder. I would like to know whether I can bypass this restriction so that koha will not look for the specific location while installing. Has anyone tried installing koha manually or has some idea on how I can do this? Please help!!! Thanks, Venita.

2 1