what about creating a new "opac-any" index in zebra?
Hello As a librairian, I think the "any" index defined in record.abs often return too much results, and inappropriate. It is *partly *caused by "any" index indexing all fields, including all notes fields (5XX in marc21, 3XX in unimarc), and of a lot of fields that could be usefull for staff but not for our public (internal item notes, statistic codes, date/place of publication etc). I want to submit you an idea : - creating a new index in zebra, matching only "usefull" fields and subfields (and it will be editable by all libraries...). For example we could call it "opac-any" - modifying the templates so that this index may be used instead of "any" when somebody makes a search in opac. What do you think of that? Regards, Mathieu Saby Rennes 2 University -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
Mathieu,
As a librairian, I think the "any" index defined in record.abs often return too much results, and inappropriate. It is partly caused by "any" index indexing all fields, including all notes fields (5XX in marc21, 3XX in unimarc), and of a lot of fields that could be usefull for staff but not for our public (internal item notes, statistic codes, date/place of publication etc). I want to submit you an idea : - creating a new index in zebra, matching only "usefull" fields and subfields (and it will be editable by all libraries...). For example we could call it "opac-any" - modifying the templates so that this index may be used instead of "any" when somebody makes a search in opac.
What do you think of that?
I like the idea, though I would prefer to use the bib-1 attribute intended for that (there is one, though I forget which and can't check just now). Logistically speaking, however, this is quite difficult. Record.abs and its DOM equivalents are files on a file system, and cannot be edited from the staff client. This is not an insoluble problem, but making this possible in a way that could be integrated with solr without forcing us to go back to primitive GRS-1-style indexes would take some doing. As an initial step, you might consider submitting a patch that adds the hardcoded index and allows librarians to choose which keyword index to use on the OPAC and staff client. This shouldn't be too hard. Regards, Jared
Jared Camins-Esakov a écrit :
Mathieu,
As a librairian, I think the "any" index defined in record.abs often return too much results, and inappropriate. It is partly caused by "any" index indexing all fields, including all notes fields (5XX in marc21, 3XX in unimarc), and of a lot of fields that could be usefull for staff but not for our public (internal item notes, statistic codes, date/place of publication etc). I want to submit you an idea : - creating a new index in zebra, matching only "usefull" fields and subfields (and it will be editable by all libraries...). For example we could call it "opac-any" - modifying the templates so that this index may be used instead of "any" when somebody makes a search in opac.
What do you think of that?
I like the idea, though I would prefer to use the bib-1 attribute intended for that (there is one, though I forget which and can't check just now). Logistically speaking, however, this is quite difficult. Record.abs and its DOM equivalents are files on a file system, and cannot be edited from the staff client. This is not an insoluble problem, but making this possible in a way that could be integrated with solr without forcing us to go back to primitive GRS-1-style indexes would take some doing.
When I wrote "editable by all libraries..", I meant editable-in-the-hard-way (record.abs etc). It would be better than nothing...
As an initial step, you might consider submitting a patch that adds the hardcoded index and allows librarians to choose which keyword index to use on the OPAC and staff client. This shouldn't be too hard.
I will try to do that next week. I add that as many libraries we are looking forward for SolR, so I won't spend weeks of work for reconfiguring Zebra based search, but even little improvements will be helpful for our users ;-)
Regards, Jared
Regards Mathieu -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
Mathieu, When I wrote "editable by all libraries..", I meant
editable-in-the-hard-way (record.abs etc). It would be better than nothing...
Ah. Yes. This is an excellent idea. :)
As an initial step, you might consider submitting a patch that adds the
hardcoded index and allows librarians to choose which keyword index to use on the OPAC and staff client. This shouldn't be too hard.
I will try to do that next week. I add that as many libraries we are looking forward for SolR, so I won't spend weeks of work for reconfiguring Zebra based search, but even little improvements will be helpful for our users ;-)
I am looking forward to Solr too, but it will be a while before it is ready for production, and I don't think it will ever be able to completely replace Zebra. It requires much more powerful hardware than many libraries can afford. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
If you want, you can make comments on this new bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 "Create a new index for OPAC simple search, more specific than "any" Todo : - check bib1.att & ccl.properties to see if some index not used in Koha today could be used. If nothing usable, create completely new index. - edit record.abs for unimarc, marc21 and normarc biblios - edit DOM config files for unimarc, marc21 and normarc biblios - check if it is necessary to edit zebra config files for authorities - edit the templates - maybe edit some perl files" I will begin to work on it next week. Regards, Mathieu Saby Rennes 2 University Le 24/10/2012 16:06, Jared Camins-Esakov a écrit :
Mathieu,
As a librairian, I think the "any" index defined in record.abs often return too much results, and inappropriate. It is partly caused by "any" index indexing all fields, including all notes fields (5XX in marc21, 3XX in unimarc), and of a lot of fields that could be usefull for staff but not for our public (internal item notes, statistic codes, date/place of publication etc). I want to submit you an idea : - creating a new index in zebra, matching only "usefull" fields and subfields (and it will be editable by all libraries...). For example we could call it "opac-any" - modifying the templates so that this index may be used instead of "any" when somebody makes a search in opac.
What do you think of that?
I like the idea, though I would prefer to use the bib-1 attribute intended for that (there is one, though I forget which and can't check just now). Logistically speaking, however, this is quite difficult. Record.abs and its DOM equivalents are files on a file system, and cannot be edited from the staff client. This is not an insoluble problem, but making this possible in a way that could be integrated with solr without forcing us to go back to primitive GRS-1-style indexes would take some doing.
As an initial step, you might consider submitting a patch that adds the hardcoded index and allows librarians to choose which keyword index to use on the OPAC and staff client. This shouldn't be too hard.
Regards, Jared
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
participants (2)
-
Jared Camins-Esakov -
Mathieu Saby