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

ByWater Solutions and Software.coop Collaborating on Koha EDI Support
by Ian Walls 13 Oct '10

13 Oct '10

Dear Koha Community, It is our pleasure to announce that software.coop of Somerset, England and ByWater Solutions LLC of Santa Barbara CA, USA, are partnering to bring Electronic Data Exchange (EDI) to Koha. EDI will greatly increase the functionality of the acquisitions module of Koha by allowing a direct electronic exchange from one entity to another, making processes such as billing and the transmission of purchase orders seamless. It may optionally accept bibliographic records from a vendor, making cataloguing quicker. It was described in the journal "Program: electronic library and information systems" Vol. 44 No. 3, 2010. The EDI code, which was written by software.coop, will be rebased by ByWater Solutions on the current head of the Koha project. The rebased code will be submitted for possible inclusion in the 3.4 release of Koha. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

4 3

Release Manager : how long (open question)
by Paul Poulain 13 Oct '10

13 Oct '10

Hi koha-devel, Chris announced that he planned to release a version every 6 months. I'm for a "time based" release management, that's the same thing. Chris has been elected as RM for Koha 3.4 but what will happend in "6 months" when 3.4 is released ? Will we elect a new RM immediatly for 3.6, that will be RM only for 6 months as well. I don't think it would be a good idea to change the RM every 6 months... So, shouldn't the RM be elected for a duration instead of for a version ? it's an open question, so let's start the thread about that... Some ideas : - 2 years or 3 major releases, the 1st that happend - 2 years - 1 year, that can be continued once (ie : after 1 year : vote to confirm the RM. If not confirmed, then, new elections) - unlimited duration, confirmed every year - ... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 3

Re: [Koha-devel] Search Engine Changes : let's get some solr
by Thomas Dukleth 12 Oct '10

12 Oct '10

Reply inline: On Tue, October 12, 2010 12:41, Thomas Krichel wrote: > > Frederic Demians writes >> >> >Just as a side note, zebra3 should be based on solr. So yet >> >another point for solr. >> >> So, isn't it the best interest of the Koha community to wait that >> Indexdata integrate Solr into Zebra? and in the meantime, switch >> Koha-Zebra interface from GRS1 to Dom in order to gain in >> granularity and customazibility. > > Yes. In any case, the zebra documentation notes that GRS1 > has been improved and replaced by DOM. > 1. WORK WHICH INDEX DATA IS DOING ALREADY. >> And as suggested by Thomas Dukleth, Koha supporters could sponsor >> directly Indexdata to speed up their work and give them a Koha >> 'direction'. Who's better than Indexdata has deep knowledge of >> search engine technlogy in Libraries arena? > > And to appear credible to them, it wouldn't be best to adopt > their recent technologies, before asking them to develop > new ones? If the Koha community would work with Index Data to support Solr/Lucene, we would not necessarily be asking Index Data to develop any new technologies which they had not already been intending to develop themselves. Index Data has added Solr/Lucene support to a several products for querying Solr/Lucene servers and integrating the result sets with Z39.50/SRU and other searches. See http://www.indexdata.com/blog/2010/09/solr-support-zoom-pazpar2-and-masterk… and http://www.indexdata.com/news/2010/10/yaz-411-available-now-solr-support . There may be some which have not yet had a public release. I did not check all the release notes. 2. WORK WHICH INDEX DATA MIGHT DO. I enquired with Index Data about the prospect of Solr/Lucene support in Zebra. Index Data has experimented with Solr/Lucene based indexing as well as other options which might be used in a next generation server for Zebra 3. A next generation version of Zebra would need some commitment of funding for development from interested parties which has apparently not been a priority from their customers most recently. However, given the work done for experimentation, the funding needed might be more modest than I would have expected otherwise. There may be other more modest options for developing support for Zebra as a Z39.50/SRU server which might be independent from Zebra as a complete indexing server if possible. What may be done with Zebra would depend upon the level of importance which the Koha community attaches to having a good Z39.50/SRU server. As I previously stated, I speculate that most libraries using Koha care very little about their own Z39.50/SRU server. Again, I will explain later the importance of Z39.50/SRU and how needing to support Z39.50/SRU for libraries is a necessity. 3. WORK FROM KNOWLEDGE INTEGRATION. I have not yet contacted Knowledge Integration to learn what is required to obtain any useful documentation for JZKit and learn whether its Z39.50/SRU feature set is as limited as it appears it may be from my examination of the source code and configuration files. 4. CLIENT VS SERVER SUPPORT FOR Z39.50/SRU. I do not think that client side support for Z39.50/SRU is enough. However, there is a potential for regression of both client and server support for Z39.50 when rewriting Search.pm without working with Index Data if they are the only company supporting the requisite software. Knowledge Integration seems to depend upon Index Data software on the client side but perhaps Knowledge Integration has some additional options to provide. I will enquire. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

1 0

Re: [Koha-devel] Search Engine Changes : let's get some solr
by Thomas Dukleth 11 Oct '10

11 Oct '10

1. REWRITING EASIER THAN BUG FIXING. I agree that as with many things in Koha there would be more work to fix Search.pm than rewrite it. I think that the CCL implementation had been partly a mistake in which Joshua Ferraro took a shortcut to reducing the work to support Nelsonville Public Library on Zebra. Joshua had previously agreed to support PQF. Some previous searching features were unnecessarily broken by the implementation which BibLibre later had to fix in subsequent versions of 3.0.X. 2. INNOVATION TO PRESERVE. Yet, there was one great achievement of Joshua's work. Searches for a title which is a stop word on many automation systems return that title sorted to the top of the result set. Searches for the title 'it' would return "It" by Stephen King. That book would be unfindable by the title in some library automation systems. We should not loose such innovations which set Koha apart from other library automation systems. 3. Z39.50/SRU IMPLEMENTATION. Where I may disagree with Paul Poulain is that completely dropping support for Zebra would be cheaper than retaining it as an adjunct to Solr/Lucene based indexing. There is a need for a sophisticated Z39.50/SRU servers for sharing records with the rest of the library community, although, perhaps most libraries now using Koha are unconcerned about having their own Z39.50 server. I hope that I would be mistaken but my investigation thus far leaves me to doubt that JZKit is a sufficient replacement for Zebra without much more work which would cost something significant. See what I reported about JZKit in section 3 of my first post in this thread, http://lists.koha-community.org/pipermail/koha-devel/2010-October/034468.ht… . My information about JZKit leads me to believe that we should be working with Index Data on using Zebra as a Z39.50 server with Solr/Lucene as they are already working on Solr/Lucene support and certainly already provide a sophisticated Z39.50 server. Furthermore, if we remove CCL support from Search.pm we do not remove the need for supporting Z39.50/SRU queries. We still need to support Z39.50/SRU queries for returning result sets from other remote systems in some user queries for resources outside the local catalogue and in copy cataloguing. I will be more complete about the continued importance of Z39.50/SRU later. 4. IMPLEMENTATION QUESTION. Henri-Damien Laurent raised an issue of DOM based indexing in point 8 of his post starting this thread. Is there an objection to using XPath indexing in general or for use with Solr/Lucene? What is that objection if any? 5. IMPLEMENTATION SUGGESTION. I think that eventually we will need distinct record designs optimised specifically for the distinct functions of editing record content, indexing, and display. For the purpose of indexing discussion and not to create too many problems at once, we could confine consideration to record design optimised for indexing. The MARC record whether in MARC format or MARCXML is poorly suited for any purpose other than as a somewhat antiquated record exchange format which is accepted throughout the library community. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

1 0

Authority merge
by Marcel de Rooy 08 Oct '10

08 Oct '10

Hi developers, I have a question on the update of biblio records after changing an authority. The 3.0 / 3.2 code in authorities.pl/AuthoritiesMarc.pm apparently replaces the complete MARC field in the biblio record (say 700) with the report tag of the authority record (say 100 for PERSO_NAME). This means that if I have an additional subfield e.g. 4 (relator code) in the biblio record with such an authority, an update of the authority record (without such a relator code) simply discards such extra subfields on the biblio side. My question is: Are we misunderstanding MARC in my library and should we always put the relator code on the authority side, or is this code doing something unintentional ?? If the first is true and I would have two separate relator codes for one authority, should I then make one authority record per relator code? It seems somewhat odd.. If the latter should be the case, I could write a bug report and submit a patch for it. Thanks for your time. Marcel

2 1

KHOA developer needed (work from home)
by Steven Saunders 07 Oct '10

07 Oct '10

Greetings, I am looking for a strong Perl developer to work on a KOHA based book/document imaging and library management system. The customer is headquartered near the East coast and this is a work from home remote development position. Both contract or employment arrangements are possible. TECHNICAL QUALIFICATIONS - Strong Perl Developer, mySQL, and Linux environments - 3 to 5 years experience preferably with larger applications - Experience in the library (electronic book management) industry a plus, but not a requirement - Experience with KOHA a plus, but not a requirement - Remote OK, employee or contractor OK PERSONAL QUALIFICATIONS These are at least as important as your technical qualifications (and the basis my business success) - Complete integrity, no exceptions - Strong problem solver who is highly productive and who always delivers - Customer focused, easy to work, no drama If this sounds like you please let me know, I would love to work with you Steve Saunders Steven Saunders Founder and Principal Sentosa Technology Consultants Cell 303.809.8043 Fax 303.834.8853 Email <mailto:steve@sentosatech.com> steve(a)sentosatech.com Web <http://www.sentosatech.com/> www.sentosatech.com AIM SteveAtSentosa cid:image001.jpg@01C9EFFC.ECB10130

1 0

[koha] mail configuraiton help
by Nitesh Rijal 05 Oct '10

05 Oct '10

Hello all. I have been running koha in my server for about 10 libraries. Each of them have a different public IP for accesssing. What are the things that I need inorder to use the mail functionality for sending overdue notices and other related functions? Is there some step by step guide for it? We already have a mail server at some other IP address, so is it possible to use that server as mail server for koha as well or is it necessary that the machine that has koha server, should also have mail server configured in it? Please reply. Regards. -- Nitesh Rijal BE IT rijal.it(a)gmail.com http://niteshrijal.com.np http://facebook.com/openrijal http://twitter.com/openrijal +9779841458173

4 8

Item barcode prefixes in 3.2
by Linda Culberson 04 Oct '10

04 Oct '10

I apologize for another newbie question, this time regarding item barcode prefixes in 3.2: We are a single-branch library that has B in front of our item barcodes which are then auto-incremental. However, unlike the documentation there is not a set itembarcodelength. So that an item barcode could be B1 or it could be B1245351. There is nothing in front of the patron barcodes which are also auto-incremental, and the B in front of the item barcode just lets us know that it applies to an item and not a person. Do I need to use javascript to handle this or is there a setting(s) that I can use for a single branch system? What I have been reading seems to apply only to consortia, and I was unclear as to whether this was still a RFC or something that was already handled in 3.2. Thanks in advance -- Linda Culberson lculber(a)mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824

2 1