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

Re: [Koha-devel] [Koha] Koha and OAI-PMH [and digital materials]
by David Cook 01 Feb '16

01 Feb '16

Hi Joel, Thanks for your email. I think I’ve sorted things out with Flo, but I wanted to come back to your email, which I’m going to cross-post to the developer listserv as well. I originally started working on an OAI-PMH harvester to create an automatic import of records from DSpace into Koha, so that Koha could show electronic resources in the catalogue. While having good item types, frameworks, and templates are good, I found the main problem to be the metadata quality. Dublin Core doesn’t translate very well to MARC. Although now that I’m re-reading your email… are you talking about making MARC records in Koha and then using DSpace’s OAI-PMH harvester to import metadata from Koha? Then attaching digital materials in DSpace while using Koha to maintain the metadata? That could be interesting… I agree that Koha needs to evolve to have better support for digital materials. However, I’m not sure what you mean by “a first-class framework for URL-only item types” though. Could you elaborate on that? Better integration into systems like DSpace may be achieved using their evolving REST APIs, although again I’m not sure what you mean by “a user might end up checking-out some digital content stored there [DSpace? Koha?] (a record is created in the issues table) that doesn’t need to check back in”. Why would you need to check out digital content in DSpace? In my experience, content is either open to the public or limited to logged in users (as part of licensing/rights restrictions). Are you thinking of something more like hosting your own ebooks in DSpace and complying with concurrent user restrictions? That could be interesting as well, although I think the majority of that work would be done in DSpace with Koha just hooking into a DSpace API to determine if there are any “available” copies for the material that they found in the Koha catalogue. I admit I’m not super familiar with ebook DRM either, so I’m not certain how much intervention would be required for expiring “on loan” DRM protected library ebooks. Personally, I find most of our Koha client libraries are interested in allowing their users to find “only electronic resources” and to provide seamless access to third-party sites like EBSCO, Proquest, and other publishers that host the actual content. EBSCO have been putting work into that with the Koha-EDS plugin, although I’d like to see more done in that area, although that’s actually more a matter of digital material publishers providing authentication and API options. If they provide the hooks, we can provide the services. I’m curious to hear your thoughts. If you have ideas for things you’d like to see, feel free to share them. If you have a budget for sponsoring development, feel free to mention that as well. It’s actually quite an exciting time to be working on Koha as large organizations like EBSCO and the National Library of Sweden are sponsoring developments in areas like OAI-PMH harvesting (which I’m working on now), moving to ElasticSearch for search and retrieval, a new REST API, etc. Even if you don’t have the money yourself, you might propose ideas on the koha-devel listserv and see if anyone is interested in sponsoring that work. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Coehoorn, Joel [mailto:jcoehoorn@york.edu] Sent: Wednesday, 27 January 2016 10:25 AM To: David Cook <dcook(a)prosentient.com.au> Cc: koha(a)lists.katipo.co.nz; flo.pouyenne(a)gmail.com Subject: Re: [Koha] Koha and OAI-PMH It sounds like she's talking about using a program that acts kind of like a web search crawler, similar to how Googlebot operates, to push information into Koha. If that's the case, I don't think Koha would be a good solution for this right now, though you might get something working via a z39.50 connection. It may be that she's asking if Koha can store and serve/circulate harvested digital content directly. Again, I don't believe Koha in it's current form would be good at this. Koha does not currently provide any place to store binary files for circulation. It may also be that she's asking if she can use Koha as a front end into something like DSpace <http://www.dspace.org/> or Greenstone <http://www.greenstone.org/> . If that's the case, I believe Koha can do this right now, but the setup is not yet easy or straightforward. In a nutshell, you would want to enter marc records for each item in the repository, just like you do for current materials, but you would want to use item types and a custom framework so that the material is presented well. I would welcome improvements in Koha to support any of those scenarios. Ultimately, I think Koha needs to evolve to have better support for digital materials. At a minimum, this means a first-class framework for URL-only item types along with first-class integration into systems like DSpace, where a user might end up checking-out some digital content stored there (a record is created in the issues table) that doesn't need to check back in. As distasteful as it may be, this probably needs to also include some kind of copyright enforcement mechanism, to allow libraries to easily comply with external licensing requirements. <http://www.york.edu/Portals/0/Images/Logo/YorkCollegeLogoSmall.jpg> Joel Coehoorn Director of Information Technology 402.363.5603 jcoehoorn(a)york.edu <mailto:jcoehoorn@york.edu> The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society On Tue, Jan 26, 2016 at 5:04 PM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Hi Florence, I'm afraid that I don't understand your question. What do you mean by "Can Koha be used to manage a digital library"? Are you asking if Koha can show metadata records from a digital library? Or are you asking if Koha can add/update/delete records in a digital library? Or both? Or something else? I'm currently working on an OAI-PMH harvester for Koha, but the sole intent at the moment is to harvest metadata records from other systems and import them into Koha. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > Date: Tue, 26 Jan 2016 15:08:31 +0000 (UTC) > From: Florence <flo.pouyenne(a)gmail.com <mailto:flo.pouyenne@gmail.com> > > To: koha(a)lists.katipo.co.nz <mailto:koha@lists.katipo.co.nz> > Subject: [Koha] Koha and OAI-PMH > Message-ID: <loom.20160126T160510-456(a)post.gmane.org <mailto:loom.20160126T160510-456@post.gmane.org> > > Content-Type: text/plain; charset=us-ascii > > Hello, > > Can Koha be used to manage a digital library ? With a OAI-PMH harvester ? > > > > ------------------------------ _______________________________________________ Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> https://lists.katipo.co.nz/mailman/listinfo/koha

1 0

New Zebra Version 2.0.62 (Relevance plus st-numeric && CHR documentation fix)
by David Cook 01 Feb '16

01 Feb '16

Hi Barton and all, Just noticed that Zebra 2.0.62 came out on the weekend: <http://lists.indexdata.dk/pipermail/zebralist/2016-January/002642.html> http://lists.indexdata.dk/pipermail/zebralist/2016-January/002642.html You’ll see “Allow @attr 2=102 for numeric index” near the bottom of the announcement. That should allow the use of “rk=()” around a query that contains a st-numeric qualifier. I haven’t tested it yet, but just a head’s up. Barton, you may find that fixes the problem you were experiencing in November. They’ve also updated the documentation for the charmap files for “equivalent” ( <https://github.com/indexdata/idzebra/commit/0e8272b3d5a18a0695f8c7a58617caa…> https://github.com/indexdata/idzebra/commit/0e8272b3d5a18a0695f8c7a58617caa…) ( <http://www.indexdata.com/zebra/doc/character-map-files.html> http://www.indexdata.com/zebra/doc/character-map-files.html) It mentions that “equivalent” is actually for searching and not for sorting. It also mentions that the equivalent directive takes place before the map directive. I think we might want to update some of our CHR files in light of this clarification. At the moment, in Koha, I think if you search for “carers” you’ll also get hits for “careers” because of the following directives: equivalent ëē(ee) map ë e map ē e I think it’s because the term “careers” would be equivalent to “carērs” and “carërs”, according to the equivalent directive. And “carērs” and “carërs” would both map to “carers” with the map directive, which means that “carers” would get hits for a “careers” value. I’ve seen the same thing with “Siemon” and “Simon”: equivalent ï(ie) map ï i equivalents: Siemon = Sïmon map: Sïmon = Simon So a search for “Siemon” would equal “Simon”. Conclusion: I think we could actually go without the “equivalent” directive and just use “map”, since “map” is for indexing, searching, and sorting. We get everything we need from “map”. I don’t think the equivalent is even 100% correct. For Scandinavian languages, this line would be incorrect: equivalent aáàãåâăąȧǎȁȃ å should actually be equivalent to “aa”. If you look at the system Zebra file scan.chr, you’ll see “equivalent å(aa)”. Anyway, just a FYI to everyone… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Barton Chittenden [mailto:barton@bywatersolutions.com] Sent: Monday, 9 November 2015 11:14 PM To: David Cook <dcook(a)prosentient.com.au> Subject: Re: Searching numeric ranges On Mon, Nov 9, 2015 at 1:33 AM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Hi Barton: I’d have to explore some more and I’ve already overstayed my day by 30 minutes. Quite understandable :-) I’d suggest adding the “SetEnv DEBUG 1” to your Apache configuration. That should output the final Search.pm query to your logs, and then you can explore from there. Yeah, I just hard coded DEBUG=1 in search.pm <http://search.pm> on my development instance. All the search debugging spam, with none of the other spam. We determined that the ranking operator/zebra construct rk( ... ) is incompatible with st_numeric :-P ... or at least that was Jesse Weaver's assessment... I was log-blind (you see too much snow, you go snowblind, you see to many logs, you go log-blind). I'll dig up more details in a bit. Thanks, --Barton I might have some time to look tomorrow though :) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Barton Chittenden [mailto:barton@bywatersolutions.com <mailto:barton@bywatersolutions.com> ] Sent: Friday, 6 November 2015 8:04 AM To: David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > Subject: Fwd: Searching numeric ranges Hey, I thought this might be in your area of expertise. The CCL part is working but once it gets inside C4/Search.pm ... god knows.... Cheers, --Barton ---------- Forwarded message ---------- From: Barton Chittenden <barton(a)bywatersolutions.com <mailto:barton@bywatersolutions.com> > Date: Thu, Nov 5, 2015 at 11:47 AM Subject: Searching numeric ranges To: Koha-devel <koha-devel(a)lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > I am working on searching lexile number ranges. ccl.properties shows lex 1=9903 r=r The 'r=r' bit means that I should be able to search using a numeric range separated by a dash, e.g. 500-600 Should return any numeric results from 500 to 600. The following query works: cgi-bin/koha/catalogue/search.pl?q=ccl%3Dlex%2Cst-numeric%3D500-600 <http://search.pl?q=ccl%3Dlex%2Cst-numeric%3D500-600> However, when I try adding that as an item in the search menu, as follows: $(document).ready(function(){ //add lexile to search pull downs $("select[name='idx']").append("<option value='lex,st-numeric'>Lexile (e.g. 600 or 550-650 )</option>"); }); That gets munged... the url reads cgi-bin/koha/catalogue/search.pl?idx=lex%2Cst-numeric <http://search.pl?idx=lex%2Cst-numeric&q=500-600> &q=500-600 And I get the following message: No results found No results match your search for 'lex,st-numeric: 500-600'. --Barton

1 0

Koha Community Newsletter: January 2016
by kohanews 30 Jan '16

30 Jan '16

Fellow Koha users: The Koha Community Newsletter for January 2016 is here: https://koha-community.org/koha-community-newsletter-january-2016/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

OAI service for Authorities
by Dhd Koha (grharry) 29 Jan '16

29 Jan '16

Hi List, I'm wondering if there is an OAI service providing authorities records. Please correct me if I am wrong. Browsing through the code, implementation would involve some SQL code I presume?? Kind Regards, Harry

3 2

Problems when using Indexdata's Zebra deb packages on Debian Jessie
by David Cook 28 Jan '16

28 Jan '16

Hi all, As Zeno Tajoli has mentioned on the "Zebra: the 'elements zebra::snippet'" thread, there are problems using Indexdata's apt repository for Zebra on Debian Jessie. It looks to me that the problems arise from YAZ 5.8.1 onwards, although YAZ 5.15.2 is the version at which we're looking. But the problem might not be with YAZ/Zebra per se. It seems to me that the problem is actually with our Zebra configuration files. Namely retrieval-info-bib-dom.xml, but also marc21-retrieval-info-bib-dom.xml, normarc-retrieval-info-bib-dom.xml, and unimarc-retrieval-info-bib-dom.xml (in debian/templates), which are used by the Debian packages. We define many front-end elements using <retrieval syntax="xml" name="something">, but we don't really need to do that. We can just use <retrieval syntax="xml" />. That gives us access to the elements we define in retrieve pipeline in the etc/zebradb/biblios/etc/dom-conf.xml file, as well as the special retrieval zebra::* elements. It seems that <retrieval syntax="xml" name="zebra::*" /> doesn't work with Zebra 2.0.61 (or I suspect more accurately recent versions of YAZ). I suspect that Zebra/YAZ is looking in etc/zebradb/biblios/etc/dom-conf.xml for the element names and failing without realizing that it's actually a special retrieval element built-in to Zebra/YAZ. All is fixed if we remove the <retrieval syntax="xml" name="zebra::*" /> and restart Zebra. Personally, I think we should remove all the <retrieval syntax="xml" name="something"> lines and just use <retrieval syntax="xml" />. That's worked on Zebra 2.0.61/YAZ 5.15.2 on Debian 8, and Zebra 2.0.60/YAZ 5.1.2 on openSUSE 13.2. I suppose the thing to do now is just open a Bugzilla bug and fix it, but I thought I'd give a more succinct FYI than I gave in my reply to Zeno (outlined below). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: David Cook [mailto:dcook@prosentient.com.au] > Sent: Thursday, 28 January 2016 12:59 PM > To: 'Tajoli Zeno' <z.tajoli(a)cineca.it> > Cc: 'koha-devel' <koha-devel(a)lists.koha-community.org>; 'Wolfram > Schneider' <wosch(a)freebsd.org> > Subject: RE: [Koha-devel] [SOLVED] Zebra: the 'elements zebra::snippet' > doesn't work > > Hi Zeno: > > I believe that I've solved the symptom, although I admit that I don't 100% > understand the root casue of the problem. > > The problem appears to be the line '<retrieval syntax="xml" > name="zebra::*" />' in "etc/zebradb/retrieval-info-bib-dom.xml". > > If you remove that and restart Zebra for your instance, you'll find that you're > once again able to use "zebra::index", "zebra::snippet", "zebra::data", > "zebra::facet::index:register:count". > > The in-depth explanation starts here: > > The vital line really is '<retrieval syntax="xml"/>'. With that line, we have > access to the special retrieval elements > (http://www.indexdata.com/zebra/doc/special-retrieval.html) as well as > the ones that we've defined in the "retrieve pipeline" in > /etc/koha/zebradb/biblios/etc/dom-config.xml, such as "zebra", "index", > "marc", and "marcxml". (See /etc/koha/sites/libraryname/zebra-biblios- > dom.cfg for the reference to /etc/koha/zebradb/biblios/etc/dom- > config.xml. Also see http://www.indexdata.com/zebra/doc/record-model- > domxml-pipeline.html for an explanation of the pipeline: "The possible > multiple <retrieve> pipeline definitions are distinguished by their unique > name attributes, these are the literal schema or element set names used in > SRW, SRU and Z39.50 protocol queries."). > > I'm going to guess that the problem arose with YAZ 5.8.1 2015/01/13: > "retrieval: pick matched element-set rule YAZ-813" > (http://www.indexdata.com/yaz/doc/NEWS) Here's the git commit: > http://git.indexdata.com/?p=yaz-moved-to- > github.git;a=commit;h=f24766f1e9fc5404fc0b512af8607d7f7054f4be. I > haven't read through it extensively, so I could be wrong, but perhaps it > caused some sort of problem where Zebra/YAZ was trying to find "zebra::*" > in /etc/koha/zebradb/biblios/etc/dom-config.xml. I'm guessing that it didn't > check that it was a special retrieval element and that it failed to find the > backend element in the retrieve pipeline, and that's why it failed. > > We don't actually need any of the following lines: > <retrieval syntax="xml" name="index" /> > <retrieval syntax="xml" name="marc" > identifier="info:srw/schema/1/marcxml-v1.1"/> > <retrieval syntax="xml" name="marcxml" > identifier="info:srw/schema/1/marcxml-v1.1"/> > <retrieval syntax="xml" name="zebra::*" /> > > The only thing we need is <retrieval syntax="xml"/>. That provides access to > the "marc", "marcxml", "zebra", and "index" backends defined in > /etc/koha/zebradb/biblios/etc/dom-config.xml, as well as the zebra::* > special retrieval elements. > > I've actually tested that on YAZ 5.1.2 and Zebra 2.0.60 on openSUSE, and it > works great. > > I suppose the thing to do at this point is open a Bugzilla report to change > "etc/zebradb/retrieval-info-bib-dom.xml", as well as "marc21-retrieval-info- > bib-dom.xml", "normarc-retrieval-info-bib-dom.xml", and "unimarc- > retrieval-info-bib-dom.xml". > > -- > Installed Koha and Zebra on Debian Jessie using packages from scratch: > sudo ls > wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key > add - echo 'deb http://debian.koha-community.org/koha oldstable main' | > sudo tee /etc/apt/sources.list.d/koha.list sudo apt-get update sudo apt-get > install koha-common > -- > sudo apt-get install mysql-server > <set mysql root password> > <edit /etc/koha/koha-sites.conf : INTRAPORT="8080"> sudo a2enmod > rewrite sudo a2enmod cgi sudo service apache2 restart echo 'deb > http://ftp.indexdata.dk/debian jessie main' | sudo tee > /etc/apt/sources.list.d/indexdata.list > sudo apt-get update > -- > sudo apt-get install libidzebra-2.0 > > sudo koha-create --create-db libraryname sudo a2dissite 000-default.conf > sudo vi /etc/apache2/ports.conf <add Listen 8080> sudo service apache2 > restart > > sudo xmlstarlet sel -t -v 'yazgfs/config/user' > /etc/koha/sites/libraryname/koha-conf.xml > sudo xmlstarlet sel -t -v 'yazgfs/config/pass' > /etc/koha/sites/libraryname/koha-conf.xml > > <choose MARC21 and all sample data> > <create administrator patron> > <create MARC record> > <worth noting that it appears to use CHR indexing by default> > > yaz-client unix:/var/run/koha/libraryname/bibliosocket > base biblios > find test > [109] Database unavailable -- v2 addinfo 'biblios' > <wait a few seconds> > base biblios > find test > Number of hits: 1, setno 3 > show 1 > <all good> > format xml > show 1 > <all good> > elements zebra::snippet > show 1 > [25] Specified element set name not valid for specified database -- v2 > addinfo '' > elements index > show 1 > <all good> > elements marcxml > ehow 1 > <all good> > elements marc > <all good> > -- > elements zebra > show 1 > [biblios]Record type: XML > <?xml version="1.0" encoding="UTF-8"?> > <z:info xmlns:z="http://indexdata.com/zebra-2.0" z:id="2" > z:filename="/tmp/yIjODFCwAP/upd_biblio/exported_records" z:rank="0" > z:score="" z:schema="zebra" z:size="938"/> > -- > sudo vi /etc/koha/marc21-retrieval-info-bib-dom.xml > <remove "zebra::*" entry> > sudo koha-restart-zebra libraryname > > Z> elements zebra::snippet > Z> show 1 > Sent presentRequest (1+1). > Records: 1 > Record type: XML > <record xmlns="http://www.indexdata.com/zebra/"> > <snippet name="Any" type="w"><s>test</s></snippet> > <snippet name="Any" type="w">This is a <s>test</s></snippet> > </record>nextResultSetPosition = 2 > Elapsed: 0.001125 > > Z> elements zebra::facet::title:w > Z> show 1 > Sent presentRequest (1+1). > Records: 1 > Record type: XML > <record xmlns="http://www.indexdata.com/zebra/"> > <facet type="w" index="title"> > <term coccur="2" occur="1">a</term> > <term coccur="2" occur="1">is</term> > <term coccur="2" occur="1">test</term> > <term coccur="2" occur="1">this</term> > </facet> > </record> > > I had suspected in the past that we might be re-defining retrieval elements in > the /etc/koha/marc21-retrieval-info-bib-dom.xml file... and this appears to > confirm it. > > > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > > > -----Original Message----- > > From: Tajoli Zeno [mailto:z.tajoli@cineca.it] > > Sent: Thursday, 28 January 2016 4:16 AM > > To: David Cook <dcook(a)prosentient.com.au> > > Cc: koha-devel <koha-devel(a)lists.koha-community.org> > > Subject: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't > > work > > > > Hi David and all, > > > > Il 27/01/2016 06:19, Zeno Tajoli ha scritto: > > >> Did you load an old Koha configuration and database? Or did you > > >> start > > fresh? > > >> You might need to do a Zebra re-index and a Zebra re-start. > > > > > > It is a start from fresh install and I do same Zebra re-index and a > > > Zebra re- > > start. > > > But now I try starting from a fresh debian 8 and I will say the result. > > > > I finish my test about 'elements zebra::snippet'. > > I have done 4 different installation on debian 8 (jessie) In every case: > > Install type: koha-common > > OS: Debian 8 (jessie) > > Lang: en > > Koha versione: 3.20.7.1 (oldstable) > > > > 1)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: MARC21 > > -- 'elements zebra::snippet' doesn't work > > > > 2)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: UNIMARC > > -- 'elements zebra::snippet' doesn't work > > > > 3)Zebra: 2.0.59. Repos: Koha only. MARC type: MARC21 > > -- 'elements zebra::snippet' WORKS > > > > 4)Zebra: 2.0.59. Repos: Koha only. MARC type: UNIMARC > > -- 'elements zebra::snippet' WORKS > > > > So the problem is not connect with MARC21/UNIMARC. > > > > David says that on OpenSuse Zebra 2.0.60 is ok about 'elements > > zebra::snippet'. > > > > It is not clear if it is a Debian 8 problem or an error on Zebra > > 2.0.61 > > > > I try to ask in Zebra mailing list. > > > > Bye > > Zeno Tajoli > > > > > > > > > > > > -- > > Zeno Tajoli > > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > > Email: z.tajoli(a)cineca.it Fax: 051/6132198 > > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

1 0

Re: [Koha-devel] [SOLVED] Zebra: the 'elements zebra::snippet' doesn't work
by David Cook 28 Jan '16

28 Jan '16

Hi Zeno: I believe that I've solved the symptom, although I admit that I don't 100% understand the root casue of the problem. The problem appears to be the line '<retrieval syntax="xml" name="zebra::*" />' in "etc/zebradb/retrieval-info-bib-dom.xml". If you remove that and restart Zebra for your instance, you'll find that you're once again able to use "zebra::index", "zebra::snippet", "zebra::data", "zebra::facet::index:register:count". The in-depth explanation starts here: The vital line really is '<retrieval syntax="xml"/>'. With that line, we have access to the special retrieval elements (http://www.indexdata.com/zebra/doc/special-retrieval.html) as well as the ones that we've defined in the "retrieve pipeline" in /etc/koha/zebradb/biblios/etc/dom-config.xml, such as "zebra", "index", "marc", and "marcxml". (See /etc/koha/sites/libraryname/zebra-biblios-dom.cfg for the reference to /etc/koha/zebradb/biblios/etc/dom-config.xml. Also see http://www.indexdata.com/zebra/doc/record-model-domxml-pipeline.html for an explanation of the pipeline: "The possible multiple <retrieve> pipeline definitions are distinguished by their unique name attributes, these are the literal schema or element set names used in SRW, SRU and Z39.50 protocol queries."). I'm going to guess that the problem arose with YAZ 5.8.1 2015/01/13: "retrieval: pick matched element-set rule YAZ-813" (http://www.indexdata.com/yaz/doc/NEWS) Here's the git commit: http://git.indexdata.com/?p=yaz-moved-to-github.git;a=commit;h=f24766f1e9fc5 404fc0b512af8607d7f7054f4be. I haven't read through it extensively, so I could be wrong, but perhaps it caused some sort of problem where Zebra/YAZ was trying to find "zebra::*" in /etc/koha/zebradb/biblios/etc/dom-config.xml. I'm guessing that it didn't check that it was a special retrieval element and that it failed to find the backend element in the retrieve pipeline, and that's why it failed. We don't actually need any of the following lines: <retrieval syntax="xml" name="index" /> <retrieval syntax="xml" name="marc" identifier="info:srw/schema/1/marcxml-v1.1"/> <retrieval syntax="xml" name="marcxml" identifier="info:srw/schema/1/marcxml-v1.1"/> <retrieval syntax="xml" name="zebra::*" /> The only thing we need is <retrieval syntax="xml"/>. That provides access to the "marc", "marcxml", "zebra", and "index" backends defined in /etc/koha/zebradb/biblios/etc/dom-config.xml, as well as the zebra::* special retrieval elements. I've actually tested that on YAZ 5.1.2 and Zebra 2.0.60 on openSUSE, and it works great. I suppose the thing to do at this point is open a Bugzilla report to change "etc/zebradb/retrieval-info-bib-dom.xml", as well as "marc21-retrieval-info-bib-dom.xml", "normarc-retrieval-info-bib-dom.xml", and "unimarc-retrieval-info-bib-dom.xml". -- Installed Koha and Zebra on Debian Jessie using packages from scratch: sudo ls wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - echo 'deb http://debian.koha-community.org/koha oldstable main' | sudo tee /etc/apt/sources.list.d/koha.list sudo apt-get update sudo apt-get install koha-common -- sudo apt-get install mysql-server <set mysql root password> <edit /etc/koha/koha-sites.conf : INTRAPORT="8080"> sudo a2enmod rewrite sudo a2enmod cgi sudo service apache2 restart echo 'deb http://ftp.indexdata.dk/debian jessie main' | sudo tee /etc/apt/sources.list.d/indexdata.list sudo apt-get update -- sudo apt-get install libidzebra-2.0 sudo koha-create --create-db libraryname sudo a2dissite 000-default.conf sudo vi /etc/apache2/ports.conf <add Listen 8080> sudo service apache2 restart sudo xmlstarlet sel -t -v 'yazgfs/config/user' /etc/koha/sites/libraryname/koha-conf.xml sudo xmlstarlet sel -t -v 'yazgfs/config/pass' /etc/koha/sites/libraryname/koha-conf.xml <choose MARC21 and all sample data> <create administrator patron> <create MARC record> <worth noting that it appears to use CHR indexing by default> yaz-client unix:/var/run/koha/libraryname/bibliosocket base biblios find test [109] Database unavailable -- v2 addinfo 'biblios' <wait a few seconds> base biblios find test Number of hits: 1, setno 3 show 1 <all good> format xml show 1 <all good> elements zebra::snippet show 1 [25] Specified element set name not valid for specified database -- v2 addinfo '' elements index show 1 <all good> elements marcxml ehow 1 <all good> elements marc <all good> -- elements zebra show 1 [biblios]Record type: XML <?xml version="1.0" encoding="UTF-8"?> <z:info xmlns:z="http://indexdata.com/zebra-2.0" z:id="2" z:filename="/tmp/yIjODFCwAP/upd_biblio/exported_records" z:rank="0" z:score="" z:schema="zebra" z:size="938"/> -- sudo vi /etc/koha/marc21-retrieval-info-bib-dom.xml <remove "zebra::*" entry> sudo koha-restart-zebra libraryname Z> elements zebra::snippet Z> show 1 Sent presentRequest (1+1). Records: 1 Record type: XML <record xmlns="http://www.indexdata.com/zebra/"> <snippet name="Any" type="w"><s>test</s></snippet> <snippet name="Any" type="w">This is a <s>test</s></snippet> </record>nextResultSetPosition = 2 Elapsed: 0.001125 Z> elements zebra::facet::title:w Z> show 1 Sent presentRequest (1+1). Records: 1 Record type: XML <record xmlns="http://www.indexdata.com/zebra/"> <facet type="w" index="title"> <term coccur="2" occur="1">a</term> <term coccur="2" occur="1">is</term> <term coccur="2" occur="1">test</term> <term coccur="2" occur="1">this</term> </facet> </record> I had suspected in the past that we might be re-defining retrieval elements in the /etc/koha/marc21-retrieval-info-bib-dom.xml file... and this appears to confirm it. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Tajoli Zeno [mailto:z.tajoli@cineca.it] > Sent: Thursday, 28 January 2016 4:16 AM > To: David Cook <dcook(a)prosentient.com.au> > Cc: koha-devel <koha-devel(a)lists.koha-community.org> > Subject: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work > > Hi David and all, > > Il 27/01/2016 06:19, Zeno Tajoli ha scritto: > >> Did you load an old Koha configuration and database? Or did you start > fresh? > >> You might need to do a Zebra re-index and a Zebra re-start. > > > > It is a start from fresh install and I do same Zebra re-index and a Zebra re- > start. > > But now I try starting from a fresh debian 8 and I will say the result. > > I finish my test about 'elements zebra::snippet'. > I have done 4 different installation on debian 8 (jessie) In every case: > Install type: koha-common > OS: Debian 8 (jessie) > Lang: en > Koha versione: 3.20.7.1 (oldstable) > > 1)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: MARC21 > -- 'elements zebra::snippet' doesn't work > > 2)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: UNIMARC > -- 'elements zebra::snippet' doesn't work > > 3)Zebra: 2.0.59. Repos: Koha only. MARC type: MARC21 > -- 'elements zebra::snippet' WORKS > > 4)Zebra: 2.0.59. Repos: Koha only. MARC type: UNIMARC > -- 'elements zebra::snippet' WORKS > > So the problem is not connect with MARC21/UNIMARC. > > David says that on OpenSuse Zebra 2.0.60 is ok about 'elements > zebra::snippet'. > > It is not clear if it is a Debian 8 problem or an error on Zebra 2.0.61 > > I try to ask in Zebra mailing list. > > Bye > Zeno Tajoli > > > > > > -- > Zeno Tajoli > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > Email: z.tajoli(a)cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

1 0

It's that time - Calling for a dev meeting in IRC - Feb 2nd
by Brendan Gallagher 28 Jan '16

28 Jan '16

Hello All - I'd like to call for a dev meeting(QA meetup/catch up) for Feb 2nd at 15utc. The reason there is such short notice was that I thought we should complete the meeting so we can bring any announcements to the General IRC meeting the following day. Please see the agenda. https://wiki.koha-community.org/wiki/Development_IRC_meeting_2_February_2016 Time converter - http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IR… Thanks much, B -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher

3 2

Do we use '"zebra::*"' only for facets ?
by Zeno Tajoli 26 Jan '16

26 Jan '16

Hi to all, as I say in previous thread I have problems with retrieval data from zebra::*. Now I want to check how we use the zebra::*. As I see from the code and from comment in git repo, we use zebra::* only for facets, with instruction: C4/Search.pm: my $facet_element = 'zebra::facet::' . $facet_idx . ':0:' . $facetMaxCount; Is it correct ? Bye Zeno Tajoli

2 1

koha-plack --enable does not enable plack when plack has never been enabled
by philippe kloos 26 Jan '16

26 Jan '16

hello, When running koha-plack --enable, the script assumes that there is already a commented line that includes the plack configuration in the apache virtual host's config of the instance. The script would comment out the line : (from /usr/sbin/koha-plack line 148) : sed -i 's:^\s*#$\s*Include /etc/koha/apache-shared-opac-plack.conf$$:\1:' "$instancefile" sed -i 's:^\s*#$\s*Include /etc/koha/apache-shared-intranet-plack.conf$$:\1:' "$instancefile" For old fashioned installs there is no commented line that includes plack configuration, so the regular expression doesn't match and the script doesn't enable plack. In my config (we've set up koha 3 years ago) i had to add the plack-related line directly in the apache virtual host config. Since the included files use the ${instance} variable, i had to define that variable as well in my vhost config : Define instance myinstancename (the "Define" keyword is not well documented in the apache docs ; i used it because SetEnv didn't work). Instead of commenting out the (possibibly non-existent) plack related lines, it is possible to find where the "/etc/koha/apache-shared-{opac,intranet}.conf" files are included and add the two relevant lines : --- a/debian/scripts/koha-plack +++ b/debian/scripts/koha-plack @@ -144,9 +144,9 @@ enable_plack() local instancefile=$(get_apache_config_for "$instancename") if ! is_plack_enabled $instancename; then - # Uncomment the plack related lines for OPAC and intranet - sed -i 's:^\s*#$\s*Include /etc/koha/apache-shared-opac-plack.conf$$:\1:' "$instancefile" - sed -i 's:^\s*#$\s*Include /etc/koha/apache-shared-intranet-plack.conf$$:\1:' "$instancefile" + # Define the instance name and add the plack related lines for OPAC and intranet + sed -i "s:^$\s*$$Include /etc/koha/apache-shared-opac.conf$:\1\2\n\1Define instance $instancename\n\1Include /etc/koha/apache-shared-opac-plack.conf:" "$instancefile" + sed -i "s:^$\s*$$Include /etc/koha/apache-shared-intranet.conf$:\1\2\n\1Define instance $instancename\n\1Include /etc/koha/apache-shared-intranet-plack.conf:" "$instancefile" [ "${quiet}" != "yes" ] && warn "Plack enabled for ${instancename}" return 0 else To disable plack, one could remove the two added lines (although removing the "Define instance $instancename" line could have side effects). Should i file a bug about this ? Regards, Philippe K. https://laretive.info

2 1

Koha bugzilla now using https
by Chris Cormack 26 Jan '16

26 Jan '16

Hi all bugs.koha-community.org is now being served over https, which is cool. However you will need to tell git bz to use https This is as simple as running git config --global bz-tracker.bugs.koha-community.org.https true (I think it should work without the --global, if you run it in your koha checkout too) I have updated the wiki documentation for git bz also, the kohadevbox will need to be updated at some point also Chris

2 1