Re: [Koha] Let's fix it together!
Daniel, I don't know if this is within the scope of the project, but as an example of a search that doesn't work, last year I spent a lot of time effort failing to come up with a search query that would show all new titles at a branch. I constructed a CCL query I thought would return biblios having at least one item with both a given branch and an acquisition date in the last 30 days. But among the search results was a biblio with two items, one at the desired branch but acquired more than 30 days ago, and one acquired in the last 30 days but at a different branch. Galen ultimately confirmed for me that you can't query for an item that meets two conditions, as CCL queries extend across the whole biblio--if one item in a biblio meets one of the conditions and another item meets the other condition, the biblio is returned. There are two issues going on with this search. The first is the indexing configuration which is not part of the proposal. The second is the query syntax. If we fixed the indexing (which wouldn't be too hard), writing a search that took advantage of the composed index would still be highly problematic. In fact, I think the only way to do it right now would be to use PQF to do a regular expression search to find all books added at a branch in the last two months. I'm making up a new composed index that consists of branch|acquisition date, and may be putting some of the terms in the wrong order but here's an example of what I mean: pqf=@attr 3=1 @attr 5=102 @attr 2=3 @attr 1=9952 branch|20120[67] You could try the following, as well, though I wouldn't really recommend it: ccl=itemacq,regexp-1,first-in-field:branch|20120[67] I'm sure a similar search would be possible in Solr, as well, but it would not be portable. Once you figured how how to do the search in Zebra, you would have to start all over again if you decided to switch to Solr or vice versa. In contrast, if we parsed queries ourselves, that search could be: itemacq like ^branch|20120[67] (and it would work in both search engines) You could also, of course, just use the PQF search and it would be translated into something that Solr could understand. Hope that helps clarify. Regards, Jared -- Jared Camins-Esakov Bibliographer, C P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcam...@cpbibliography.com (web) http://www.cpbibliography.com/ ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Let's fix it together!
Hello. We want your feedback in this process. We don't want to develop in a vacuum. It would be nice to have a few discussions like we did with holds slips. I would like to amplify on this a little bit. We *really* want your feedback on search. In fact, it is an absolute requirement for bringing Koha's search up to where it should be. We need examples of searches that don't work, and also examples of searches that work really well. Both types of searches need to be working at the end of this process. Before any code is written, we're going to have to come up with a set of tests that allow us to determine when the work is finished. Some work was done on the wiki, documenting some searches that should work in Solr ( http://wiki.koha-community.org/wiki/Solr/Lucene_Test_Queries_for_Koha ) but we need more examples. We'll need people to test things and to run searches that will make us laugh and cry. Actually, this reminds me of a joke. A bibliographer is at the police station for some business, and is asked for some fingerprints... sorry, I'll refrain. I would welcome any interesting searches you could send this way, though (and if possible please include a link to your catalog so I can see why Koha is giving you the results you are getting). Regards, Jared -- Jared Camins-Esakov Bibliographer, C P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcam...@cpbibliography.com (web) http://www.cpbibliography.com/ ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Let's fix it together!
Hi, Thanks for taking the initiative on this! I don't know if this is within the scope of the project, but as an example of a search that doesn't work, last year I spent a lot of time effort failing to come up with a search query that would show all new titles at a branch. I constructed a CCL query I thought would return biblios having at least one item with both a given branch and an acquisition date in the last 30 days. But among the search results was a biblio with two items, one at the desired branch but acquired more than 30 days ago, and one acquired in the last 30 days but at a different branch. Galen ultimately confirmed for me that you can't query for an item that meets two conditions, as CCL queries extend across the whole biblio--if one item in a biblio meets one of the conditions and another item meets the other condition, the biblio is returned. I hope all that was clear. Thanks again, Daniel On Mon, Jul 23, 2012 at 10:01 AM, BWS Johnson abesottedphoe...@yahoo.com wrote: Salvete! Let's fix it together! In June, there was discussion on the list dealing with search. [1] I had long been a proponent of Don't touch it! I love it! It works! As Koha matured, the search slipped a little. I get annoyed when I find preferences that result in stunningly different search results on different catalogues. I don't want there to be a large discrepancy in what users can find at one Library and won't ever find at another if both Libraries run Koha. Some search related system preferences are somewhat counter-intuitive, and not nearly as helpful as one might hope. I resigned myself to sadly nodding my head when I checked on the behaviours mentioned in the listserv discussion. Jared mentioned wanting to see search fixed on IRC, so I challenged him to be the one to take it on. I still think we have a better search than most ILSs, but I want to get back to being the best out there by far. We've talked about group financing of enhancements before. Sometimes this happens. I feel that a lot of enhancements for Koha don't come to fruition because folks are scared to ask for aestimates, or realise that they can't afford it all on their own. Your Library doesn't have to sponsor this on its own. If you've not put in for developments recently, we urge you to do so now. If you know about an appropriate grant for this sort of work, do let me know. I'll take a shot at writing it. Jared is willing to bang his head against this project. I am willing to run test searches. I asked him to dice things up so that people can afford to contribute. Some subcomponents of the rewrite will only run about $3000. The loose aestimate for the entire first phase is roughly $70,000. I realise that budget times are tight, but we're hoping with a new fiscal year, now might be a good time to act on fixing a major stumbling block to usability. If we split the costs, this is eminently doable and will happen sooner rather than later. Jared and I want to make this better for users, but neither of us can afford to do so for free. We want your feedback in this process. We don't want to develop in a vacuum. It would be nice to have a few discussions like we did with holds slips. You can see what we're talking about here: https://trello.com/board/search-rewrite/4ff86aadd9b1c1436f2aefee Ask Jared for an invitation if you want to modify it. We'll also be adding material under the RFCs section of the Community Wiki. We'll need people to test things and to run searches that will make us laugh and cry. So let's do it. Let's make it happen. Let's make Koha better. [1]http://lists.katipo.co.nz/pipermail/koha/2012-June/033230.html Cheers, Brooke ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
