January 2005 - Koha - lists.katipo.co.nz

2.2.0 Roadmap
by Paul POULAIN 24 May '05

24 May '05

Hi Koha fans, Chrismas & new year approches, so, i wanted to share with you the roadmap of Koha : * today, i'll release Koha 2.2.0RC5. Fixes a few problems, and adds few features. * I'll be away of the web from tuesday 21 to january, 3rd. But don't worry, i'll continue hacking a little bit Koha. In fact, i plan to do 3 things : - write scripts to migrate a library that will adopt Koha in 2005Q1. - write a DOC to explain deeply how to migrate datas from XX to Koha, and tune all Koha parameters (authorized values, authorities...) to have a perfectly working cataloguing tool. Will be in french, so translators fr => en are welcomed. - "copy" improved virtual shelves tools into OPAC. * On January, 3rd, for my return, unless there is a major problem appearing, i'll release official 2.2.0 !!! This date has been choosen because it will be the 5th birthday of our preferred ILS. A great date, really. TECHNICAL info : i'll create a new branch in CVS for 2.2.0 on january. Until then, please, just commit bugfixes and/of minor improvements in the HEAD branch. At least, commit NOTHING that needs a change in the DB. Note that 2.2.x will probably contain some great tools being developped by Nelsonville at the moment. don't be too impatient, just know that it will be really great (for public libraries, just nice for search libraries) ;-) PRIVATE info : today, it's my 10th wedding birthday ;-) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 1

Re: Re: [Koha] Is there a language field in mysql tables?
by BWS Johnson 07 Feb '05

07 Feb '05

Salvete! There's an interesting thread on the American Government Documents listserv right now on OPAC displays, and I figured it might cause interesting discussion here. I have forwarded one of the messages below. I am aware that any change to the OPAC would probably involve an awful lot of work, and I try very hard not to beg and plead for anything I'm not paying for, so please don't take this as an immediate request for implementation, but rather something to gnaw on as we all try and figure out what configuration suits our patrons. Cheers, Brooke @ Hinsdale MA I am not a cataloger. But I'm intrigued by the interplay between the (very important) issue of OPAC display that Barbie focused in on and on the draft document's question about FRBR-related consequences of multiple records. It seems to me that describing each item or instance (I don't remember the exact FRBR nomenclature) makes sense, provided that those records can be grouped into a work-level record for display so that (in my understanding) we would get one hit for Statistical Abstract of the United States with four or five instance records hanging off of it, one each for web, cd, micro, print and (locally for us) one for a commercial reprint and several for commercial online versions. My patrons would love to find ONE record that describes "The Starr Report" or "9/11 Commission Report" and includes a list of all the instances of that work, regardless of format (or publisher). Similarly, if I had one "work" record to display for Code of Federal Regulations that somehow had my print, fiche and electronic holdings attached to it, swell. I don't know what FRBR-type displays will require -- it seems like separate records per format -- but workflow issues aside, eventually getting all the instances of a work grouped into one display (regardless of how man records underlie the display) would be my ideal OPAC. As far as I know, our ILS (III) won't do this, at least not yet. If Aleph handles FRBR-ized display, cool. (I do agree with Barbie that GPO cataloger time is valuable, so lower-level records for other formats makes sense to me, as long as one format gets the full treatment.) I'd love to spend some time at Spring FDLP discussing this. Scott

4 4

apache2 permission pain over...
by Adam Steer 03 Feb '05

03 Feb '05

Allright! This has bugged me for ages, and it is finally solved - I should have realise loooong ago. If you use apache2, don't forget to allow access to your directories when you're done installing koha [just like everywhere else in apache2 - duh!] For example, where koha-http.conf says: ..... DocumentRoot /usr/local/koha/opac/htdocs/ ServerName server.ip.address ..... I needed to add something like: ..... DocumentRoot /usr/local/koha/opac/htdocs/ <Directory "/usr/local/koha/opac/htdocs"> Order allow,deny Allow from ... Deny from ... </Directory> ServerName server.ip.address ScriptAlias /cgi-bin/koha/ /usr/local/koha/opac/cgi-bin/ <Directory "/usr/local/koha/opac/cgi-bin"> Order allow,deny Allow from ... Deny from ... </Directory> ..... This may be due to running Koha on a server that's pretty well tied up from the outside world, or a messy apache2 config - but I just thought I'd have a victory dance and share. So, Koha 2.2 can run on SuSE9.1/Apache2. There ya go. Off to wrestle MacOS now :-) Cheers! Adam. -- Adam Steer Web publishing officer Australian Library and Information Association adam.steer(a)alia.org.au http://alia.org.au ph 02 6215 8234 fx 02 6282 2249

3 2

Z39.50: Can't call method "size" on an undefined value
by Giuseppe.Angilella＠ct.infn.it 01 Feb '05

01 Feb '05

Hi everybody, I eventually managed to have a Z39.50 client running here (Koha 2.2.0RC5 on RedHat 9.0). Looking at the log file, it seems that the client does connect to the (various) servers defined, since I can read lines such as: 10027/16 : Processing isbn=0691043655 at LIBRARY OF CONGRESS, WASHINGTON DC, USA z3950.loc.gov:7090 voyager MARC21 (6 forks) 10027/16 : 2 >> 10027/16 : creating and 10027/16 : working on results entry 62 10027/16 : connected to LIBRARY OF CONGRESS, WASHINGTON DC, USA However, after a search has been done, I get error messages such as: Can't call method "size" on an undefined value at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 277. I tried to edit the processz3950queue script, and line 277 is indeed where size() is first called: my $numresults=$rs->size(); (Line numbering may be different from your copies of processz3950queue, since I had to include the line: my $context = C4::Context->new("/etc/koha.conf"); as suggested in previous postings, to have processz3950queue working.) I believe that a search has been done, but the results cannot be retrieved and/or saved in Koha's database, because at this point the perl script generates the above error. In addition to that, and seemingly independently from that, processz3950queue enters a loop, with many lines like starting loop in the log file. I did specify export LIB5PERL=/usr/local/koha/intranet/modules and did start the Z39.50 client via ./z3950-daemon-launch.sh Any help? Thank you again in advance. Giuseppe.

4 3

Koha contacts in Minnesota
by md 31 Jan '05

31 Jan '05

Hello Is there anyone on this list or does anyone know if there are Koha users in Minnesota? Preferably in the Minneapolis/St. Paul area. If not, is there anyone perhaps in a University environment (library school?) who has been working with Koha and knows it well? Thank you!

1 0

Re: Re: [Koha] Is there a language field in mysql tables?
by Steven F. Baljkas 28 Jan '05

28 Jan '05

Tuesday, January 25, 2005 00:45 CST Hi, Rachel, Just wanted to add that having the language field would probably be useful for more libraries than not. Albert C. responded to the listserv noting the MARC21 field 041 where language info can be coded (the predominant language of the material in hand should be coded in the 008 fixed field, positions 35-37 inclusive, and this is often considered sufficient coding if the work in question is monolingual). If I understood Zhang's message correctly, though ("I don't need the MARC info too"), that was less of an issue than having the info in the core SQL tables (right?). That distinction brings to mind the question of whether Koha is running off of the MARC records it imports or the tables it populates, stuff which makes cataloguing staff worry. Another notendum: books can be in more than one language. This is fairly common in Canada, where federal and many provincial documents are flip-flop bilingual editions. A more scholarly example, brought to mind by Brooke's regular Latin salutation, is the entire Loeb classical library (Latin or Greek on left page, English translation on right). Whatever the example, MARC coding allows for multiple languages being noted in the 041 but what does Koha do with that data? Just seeking a little clarification on this, Amitiés, yours, confused (as usual), Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada > From: Rachel Hamilton-Williams <rachel(a)katipo.co.nz> > Date: 2005/01/24 Mon PM 05:18:07 CST > To: Zhang Chunxiao <tzhcx(a)hotmail.com> > CC: koha(a)lists.katipo.co.nz > Subject: Re: [Koha] Is there a language field in mysql tables? > > Hi Zhang > > > > Sorry.I mean that if there is a language field which stores the language > > of books,not the language of the Koha interface. > > We did put one in for UNIDO - they have books in different languages and > wanted people to be able to search on that basis - however that was a > modified 1.9 I think, and I don't think that field is in the new version. > > We are doing an upgrade for UNIDO at the moment, and I'm assuming that's > one of the things we'll be changing, so would you like that added to the > general release, and I'm assuming you would just choose the UNIDO > templates to access it? > > It will be a few weeks away, but hopefully not more than that. > > Cheers > Rachel > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha

3 2

migrating 852 holdings Microlif Marc21
by mike re-v 27 Jan '05

27 Jan '05

hi fyi looks like the current koha wiki submissions are not being seen by google. perhaps the login requirement is hiding the content. I have several useful scripts on migrating from Microlif, Marc21,852 holdings ILS vendors. this is a direct link you might be required to login the user is koha paswd kohatoo http://www.saas.nsw.edu.au/koha_wiki/ re-v __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

1 0

Z39.50 daemon script problem
by Michael Nelson 27 Jan '05

27 Jan '05

I have installed Koha 2.2.0 on Redhat 8.0 and it is running well. I am trying to get Z39.50 search to work. I tried running the z39.50-daemon-launch.sh and get no error messages on the console. But when I look at the log I see the errors below. Any ideas on what is wrong. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 107. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 108. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 109. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 110. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 111. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 187. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 188. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 189. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 190. Global symbol "$context" requires explicit package name at /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue line 191. Execution of /usr/local/koha/intranet/scripts/z3950daemon/processz3950queue aborted due to compilation errors. Office: NCB 256, mnelson(a)uwo.ca Michael Nelson, Associate Professor Faculty of Information and Media Studies North Campus Building, Room 240 University of Western Ontario, London, Ontario, Canada N6A 5B7 Phone: 519-661-2111x88507 Fax:519-661-3506

2 1

Re: Re: [Koha] Is there a language field in mysql tables?
by Steven F. Baljkas 27 Jan '05

27 Jan '05

Wednesday, January 26, 2005 17:56 CST Hi, Rachel, Thank you very much for the detailed answer. I think I actually understand the KohaDB-MARCDB relationship now! (Of course, the roof will probably fall in on me any second now.) > So would you want the ability to restrict your search > based on language as a default search field as well? Yes, that would be one useful result of using language encoding within MARC records. I would guess that your take on having the ability to search by language is right on; it would be a useful limiter for larger library settings, but ignored by most other library types. Nevertheless, I would say that *language is a must have.* It can be safely ignored by those who do not need it, but it is a very useful perq for those who do. Would it be practicable to have language as a category but something that smaller libraries could set to the default language once and then not have to worry about it? That would be comparable to what Voyager (what LC uses) and other ILS do: the default is English, but you can change that with any given advanced search. > [there are usually at least 2 sides to such a question] > - what is in the koha DB, what is in MARC, how can that > data be searched on, and how will that affect the > display.... I don't know if there would be a simple answer regarding the display, but I would assume most people would recognise a language if they read it, so other than languages with non-Roman scripts (a whole other world of fun that I believe Gerry Arthus and others are dealing with in the Asian arena) there would be no need to complicate Koha's OPAC display. In other words, just sidestep it for now. ;-) > Sooo, while you can assume that pretty much any field is > in the MARC record I think (with 900 odd fields it seems > a safe bet :-), Oh yeah! ;-) > depending on what you then want to do with the data, you > might need a field for it in the koha db as well - and to > map the two together. [snip: passage on language data > coding locations: MARC21 tag 041, MARC21 tag 008, > positions 35-37 inclusive] > > I believe (and someone else might want to jump in and > correct me here) that the answer is "both" or possibly > "either". If "either" or "both" are the answers, then I should think it would be best to create a field in the KohaDB for language information, whether for MARC-on or MARC-off. > When you set up your Koha you can choose to have it > running in "marc mode" or not - if you choose "not" then > I believe it doesn't "show" the MARC and pretty much runs > off the Koha db. If it were, MARC-off, the library would set language, I'd suppose, once or individually with each record in non-MARC fashion (as a note? I am sorry, I really don't know: my training was MARC-based and I only vaguely remember ever seeing language noted on catalogue cards way-back-when). If it were MARC-on flavour, then Koha should look first to those fixed positions in tag 008 (35-37) to determine the language of the material (a series of standardised 2-3 abbreviations which, I imagine could be set up as a table so that Koha would convert the info into human-friendly words), and then, check if there is a 041 tag that provides additional information (same abbreviations). For many records there probably would not be a 041, but it would be nice to check anyway. > [snip] So an item needs a language field that is more > like subjects, where you can have more than one. Yes, that would be the case. BTW, this is a whole separate issue from the language in which the OPAC displays. That should be set separately. It is quite likely, for example, that a French library benefitting from Paul's work, would have a Koha OPAC display in French, and yet have English, German, etc. works that would be available in the library. A typical university library would have the display set in the language of its student/staff-base but have records for items in dozens of languages. Those are my main thoughts on the language matter. I've got a few PS's below on a few other points less germaine but perhaps of interest to some. Thanks again, Rachel, for the great answer e'mail, and please record my vote, along with the UNIDO staff, for having a language identifier as a must have feature. Cheers, your slightly less confused, still frozen Koha enthusiast in ice-cold Winnipeg, MB, Canada Steven F. Baljkas P.S. Re: > There are usually 2 sides (at least :-) to a question > like this Oh, I hear you. In library tech training, the most common answer we got from our instructors was "it depends"! :-) > I think that you can search either the koha db (smaller > and faster) or the MARC db (bigger and slower). The koha > db is I think a subset of the MARC db - and is basically > automatically "joined" to the marc db, so that the two are > kept in sync. Thank you, thank you, thank you, Rachel! I was never completely clear on this before. I think it falls under the category of stuff that is completely clear to programmers but less so for the rest of us. I remember there were a dozen or so messages in a row a few years ago on these issues and I never quite understood what they were talking about with speed as Koha seems to me quite fast. > Additional info about an item is added to the Koha part - > about it's life since entering the library, which MARC > isn't interested in. Actually, that bit is not true, Rachel. Most libraries ignore stuff like that, but there is actually a 583 tag, Action Note, that libraries (including 3 that I've worked in) use to record various information about what's happened to the book since it started it's library life. Formally, 583 is for "processing, reference and preservation actions", but given the broader meaning of the first term, that can be used to justify almost anything. And, if a library wanted to keep other info on hand in MARC format there are always 59x notes. In my experience, these aren't set to display in the default non-MARC-view of the OPAC, but library staff could see them by selecting MARC-view. > There is a fair amount of info in a MARC record which lots > of libraries have no real use for, and give volunteer > cataloguers the willies. [snip] Certainly, one can understand that. Years ago now, Pate pointed me to the MARC-Lite resources, which are basically just that. Then again, the core minimum standards, which have been around for a long time, are pretty much the same.

1 0

I can not find a field to stores language of books in Koha database.
by Zhang Chunxiao 25 Jan '05

25 Jan '05

Hello,Everybody: I can not find a field to stores language of books in the Koha Database in mysql. Is there a field storing the languages? I don't mean the language of Koha's user interface. Thanks _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn

2 2