[Bug 8962] New: Create a new index for OPAC simple search, more specific than "any"
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Priority: P5 - low Change sponsored?: --- Bug ID: 8962 Assignee: gmcharlt@gmail.com Summary: Create a new index for OPAC simple search, more specific than "any" Severity: enhancement Classification: Unclassified OS: All Reporter: mathieu.saby@univ-rennes2.fr Hardware: All Status: NEW Version: unspecified Component: Searching Product: Koha In the current record.abs, the index "any" is defined as "all any". So, all the fields indexed in other indexes are also indexed in "any". So, for example, in my unimarc catalogue, if I search for "fre" in the opac, I get 342825 results, because it is the code for french language in 101a field, index in "ln". Idem if I search for "lc" or "rameau" (equivalent to LCSH in France), or "texte" And with fuzzy or autotruncate activated, it is, very very annoying. My idea is : - to keep the "all any" - to create a more specific index, matching only important field, but in any event NOT matching coded fields and some boring notes... - use this index in opac simple search (and maybe in staff interface simple search but this could be discussed...) 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 Mathieu Saby Rennes 2 University -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |mathieu.saby@univ-rennes2.f | |r -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jcamins@cpbibliography.com, | |mathieu.saby@univ-rennes2.f | |r -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #1 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- It may be preferable to use Any for the new index, and convert the old index to Anywhere. From the Attribute Set Bib-1 Semantics document (http://www.loc.gov/z3950/agency/bib1.html): Any 1016 The record is selected if there exists a Use attribute that the target supports (and considers appropriate - see note 1) such that the record would be selected if the target were to substitute that attribute. Notes: (1) When the origin uses 'any' the intent is that the target locate records via commonly used access points. The target may define 'any' to refer to a selected set of Use attributes corresponding to its commonly used access points. (2) In set terminology: when Any is the Use attribute, the set of records selected is the union of the sets of records selected by each of the (appropriate) Use attributes that the target supports. Anywhere 1035 The record is selected if the term value (as qualified by the other attributes) occurs anywhere in the record. Note: A target might choose to support 'Anywhere' only in combination with specific (non-Use) attributes. For example, a target might support 'Anywhere' only in combination with the Relation attribute 'AlwaysMatches' (see below), to locate all records in a database. Notes on relationship of Any and Anywhere: (1) A target may support Any but not Anywhere, or vice versa, or both. However, if a target supports both, then it should exclude 'Anywhere' from the list of Use attributes corresponding to 'Any' (if it does not do so, then the set of records located by 'Any' will be a superset of those located by 'Anywhere'). (2) A distinction between the two attributes may be informally expressed as follows: 'anywhere' might result in more expensive searching than 'any'; if the target (and origin) support both 'any' and 'anywhere', if the origin uses 'Any' (rather than 'Anywhere') it is asking the target to locate the term only if it can do so relatively inexpensively. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #2 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 13406 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13406&action=edit [PATCH] Bug 8962 : Create a new anywhere index (draft patch) This is a draft patch creating a new index 'anywhere'. It changes - templates for staff interface (index anywhere added to dropdown index lists) - ccl.properties - record.abs for UNIMARC : index 'any' limited to 010, 011, 071, 072, 073, 70X, 71X, 200, 205, 210c, 225adehiv, 330, 328, 4XXt, 5XX, 6XX, 995fk - record.abs for MARC21 : index 'any' limited to 02X, 030, 110, 111, 130, 21X, 22X, 24X, 260b, 4XX, 505, 520, 6XX, 7XX, 8XX, 952p You can test this way : - search "eng" or "fre" in OPAC and Staff interface => a lot of records - apply and rebuild zebra - search "eng" or "fre" in OPAC and Staff interface => 0 or few records - search "eng" or "fre" in Staff interface selecting "any words (all indexes)" index in advanced search => a lot of records Of course, we could change the list of fiels indexed in 'any', especially for Marc21 (I never used Marc21...), and the name of the new index in staff interface... M. Saby Rennes 2 University -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9234 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com Patch complexity|--- |Small patch --- Comment #3 from Kyle M Hall <kyle@bywatersolutions.com> --- I'm getting no results with "Any word (all indexes)". I copied the new ccl.properties and record.abs over my old ones in koha-dev, and reindexed zebra. What am I missing? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #4 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Hello. I will rebase the patch once bz 8984 is pushed (it will break this one), and I will see why it is not working. M. Saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #5 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- I tried to apply my patch. With unimarc flavor, it seems to work : in advanced search in staff interface, "Keyword" index gives me less results as the new "Any word (all indexes)". Maybe it is broken for marc21... Kyle, did you notice some unusual warns when you rebuild zebra ? Mathieu Saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #6 from Kyle M Hall <kyle@bywatersolutions.com> --- I don't recall seeing anything unusual when I ran rebuild_zebra.pl (In reply to comment #5)
I tried to apply my patch. With unimarc flavor, it seems to work : in advanced search in staff interface, "Keyword" index gives me less results as the new "Any word (all indexes)".
Maybe it is broken for marc21... Kyle, did you notice some unusual warns when you rebuild zebra ?
Mathieu Saby
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #7 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- And you tested on a Marc21 base I suppose? M. saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- That is correct. (In reply to comment #7)
And you tested on a Marc21 base I suppose? M. saby
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #9 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- It is still a draft, but I have rebased and completed my patch, and splitted it in 3 patches (more easy to test and to rewrite). It is still only for GRS1 indexing. 1st patch contains CCL changes and templates changes/ 2st patch contains Marc21 changes (biblio and authorities) 3rd patch contains Unimarc changes (biblio and authorities) What should be different from before ? This patch adds a new index Anywhere in ccl.properties and add "any word" option in intranet search for using this index. Default OPAC and intranet search in still using CCL "Any" index. In record.abs for biblio and authorities, for the 2 marc flavor : - Defines a new index "anywhere" for indexing all biblio and authorities subfields. - Old "any" index is slightly more selective than before Details of changes for Unimarc : - for authorities : all fields indexed in any except 001 and notes - for biblios : index 01X, 07X, 7XX except $9, 200, 205, 210c, 225, 328, 330, 4XX, 5XX except $9, 6XX except $9 and 67/68X, 995fkr For Marc21 : - for authorities : all fields indexed in any except 001 - for biblios : fields indexed in any : 02X, 030, 110, 111, 130, 21X, 22X, 24X, 260b, 4XX, 505, 520, 6XX, 7XX, 8XX, 952p => so, for example, "any" does NOT indexes * notes (except 328/330 in Unimarc and 505/520 in Marc21) * date of publication * place of publication (town of the publisher) * extent * item notes * biblionumber To test : - apply the 3 patches - rebuild zebra biblios index - rebuild zebra authorities index - make some searches : for example, check if place of edition or notes are indexed... If it works, we need to - discuss the choice of fields that must remain in "any" - do the same for DOM indexing - do the same for Normarc M. Saby Rennes 2 University -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.poulain@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #13406|0 |1 is obsolete| | --- Comment #10 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 14871 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=14871&action=edit [PATCH 1/3] Bug 8962: Changes to CCL and templates This patch adds a new index Anywhere in ccl.properties and add "any word" option in intranet search for using this index. Default OPAC and intranet search in still using CCL "Any" index. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #11 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 14872 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=14872&action=edit [PATCH 3/3] Bug 8962: Marc21GRS1 Changes MARC21 GRS1 indexing. Defines a new index "anywhere" for indexing all biblio and authorities subfields. Make "any" index more selective than before : - for authorities : all fields indexed in any except 001 - for biblios : fields indexed in any : 02X, 030, 110, 111, 130, 21X, 22X, 24X, 260b, 4XX, 505, 520, 6XX, 7XX, 8XX, 952p -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #12 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 14873 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=14873&action=edit [PATCH 2/3] Bug 8962: UnimarcGRS1 Changes Unimarc GRS1 indexing. Defines a new index "anywhere" for indexing all biblio and authorities subfields. Make "any" index more selective than before : - for authorities : all fields indexed in any except 001 and notes - for biblios : index 01X, 07X, 7XX except $9, 200, 205, 210c, 225, 328, 330, 4XX, 5XX except $9, 6XX except $9 and 67/68X, 995fkr -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #13 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- you can test it, but please do not sign this patch before other patches regarding Unimarc Zebra are pushed : 9830, 9352, 9828 (there will be a lot of conflicts, and the logic of these patchs are diffrent from this one). Mathieu Saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Magnus Enger <magnus@enger.priv.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@enger.priv.no Depends on| |9830, 9352, 9828 --- Comment #14 from Magnus Enger <magnus@enger.priv.no> --- Adding some bugs to "Depends on", based on earlier comments. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Magnus Enger <magnus@enger.priv.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |BLOCKED --- Comment #15 from Magnus Enger <magnus@enger.priv.no> --- Setting status t o(In reply to mathieu saby from comment #13)
you can test it, but please do not sign this patch before other patches regarding Unimarc Zebra are pushed : 9830, 9352, 9828 (there will be a lot of conflicts, and the logic of these patchs are diffrent from this one).
Setting the status to BLOCKED since thos bugs are still "needs signoff". -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #16 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Thank you Magnus. But even if some conflicts could occur for UNIMARC (and maybe for Marc21 : I did not check, and the patch is rather old now...), you can try to do a 1st test anyway, or just give your opinion about the logic of the patch ;-) Mathieu -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - low |P4 Status|BLOCKED |Needs Signoff Version|unspecified |master -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #14871|0 |1 is obsolete| | --- Comment #17 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 21985 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21985&action=edit [PATCH 1/3] Bug 8962: Changes to CCL and templates This patch adds a new index Anywhere in ccl.properties and add "any word" option in intranet search for using this index. Default OPAC and intranet search in still using CCL "Any" index. Testing plan : In a Marc21 GRS-1 Koha : 1/ make some biblio searches without selecting any index (Koha will use "any" index) and note the results. Ex : search "fre", "eng", "book", "history", "history book" 2/ apply the 3 patches 3/ copy the 4 new record.abs files (Marc21 auth, Marc21 bib, Unimarc auth, Unimarc bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ check that a new choice "Any word (all indexes)" is visible in advanced search. 6/ make the same searches as 1/ : you should see less results (detailed test plan in patchs 2 and 3) 7/ in Staff interface adavanced search, select "Any word (all indexes)" and make the same searches as 1/ : you should see the same results (maybe with a slight differences, because more notes fields are indexed in Marc21) In a UNIMARC GRS-1 Koha : same test -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #14873|0 |1 is obsolete| | --- Comment #18 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 21986 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21986&action=edit [PATCH 3/3] Bug 8962: Unimarc biblios and authorithies (GRS1) This patch makes some changes UNIMARC GRS1 indexing, for indexing only some specific fields in "any" index. The patch is fully testable, and can be signed off if it works. But the list of fields I kept in "any" is rather subjective, and based as my experience as a library user: It can be discussed in followups. 1. Defines a new index "anywhere" for indexing all biblio and authorities subfields. 2. Make "any" index more selective than before : - for authorities : all fields indexed in any except 001 and notes (3XX) - for biblios : fields indexed in any : * biblio fields indexed in "any" : ** the more "user friendly" control numbers : 01X, 07X ** authors : 7XX except $9, 200$f$g ** titles : 4XX except $9, 5XX except $9, 200$a$d$e$h$i ** edition statement : 205 ** series : 225, 410, 411 ** subjects : 6XX except $9 and 67X/68X ** notes : only 327, 328, 314, 330 * items fields indexed in "any" : ** barcode : 995f ** callnumber : 995k Test plan : In a Marc21 GRS-1 Koha : 1/ apply patch 1 and this one 2/ in Staff interface, make some searches on authorities (choose "Keyword search" tab), including searches of words only present in 3XX fields. 3/ copy the 2 new record.abs files (UNIMARC auth, UNIMARC bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ make the same authorities searches as 2/ : you should get the same results, except for searches based on words only present in 3XX fields : in that case, you should not see the auth records. 6/ in default search (without selecting any index), search for some record by - its isbn - its issn - its title - its author(s) - its series name - its publisher - its summary (330 field) - several subjects - the barcode of one of its items - the callnumber of one of its items => you should find the record each time 7/ in default search (without selecting any index), search for some record by - the content of any 3XX fields (except 327,328,314,330) - the number of pages or volumes (ex : "510 p." or "1 vol") - its language code ("eng", "fre"...) - the value of 200$b (like "Texte imprimé") - its publication year - its town of publication - the content of a 670-680 field - the content of a 995 subfield (except barcode and callnumber) - the content of a 099 subfield => you should not find the record each time 8/ regression test : check that specific indexes are working as usual (title, subject, callnum, barcode, pubdate etc) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #14872|0 |1 is obsolete| | --- Comment #19 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 21987 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21987&action=edit [PATCH 2/3] Bug 8962: Marc21 biblios and authorithies (GRS1) This patch makes some changes MARC21 GRS1 indexing, for indexing only some specific fields in "any" index. The patch is fully testable, and can be signed off if it works. But the list of fields I kept in "any" is rather subjective, and based as my experience as a library user: It can be discussed in followups. 1. Defines a new index "anywhere" for indexing all biblio and authorities subfields. 2. Make "any" index more selective than before : - for authorities : all fields indexed in any except 001 - for biblios : fields indexed in any : * biblio fields indexed in "any" : ** the more "user friendly" control numbers : 020->030 ** main entries (authors and uniform title) : 1XX ** title and Title-Related Fields : 20X-24X ** publisher : 260$b ** series : 4XX ** some notes : 502 (dissertation), 520 (abstract), 505 (formated content), 511 (participant) ** subjects : 6XX ** added Entry Fields : 70X-75X ** linking Entries-General Information : 76X-78X ** series Added Entry Fields : 80X-83X * item fields indexed in "any" : ** callnumber : 952$o ** barcode : 952$p 3. Also index all the Marc21 notes (5XX) in "Notes" index (same logic as current 3XX fields indexing in UNIMARC) - new fields not indexed before : 504,506,507,508,511,513,514,515,516,518,521,522,524,525,530,533,534,535, 536,538,540,541,542,544,545,547,550,552,555,556,561,562,563,567,580,581,583,584,585,586,588 - fields indexed in "Notes" in addition to a more specific index : 502,505,521,520,510,526 4. Also index all the Marc21 notes (5XX) in "Notes" index (same logic as current 3XX fields indexing in UNIMARC) 5. Adds a lot of comments to make easier further changes and error checking Test plan : In a Marc21 GRS-1 Koha : 1/ apply patch 1 and this one 2/ in Staff interface, make some searches on authorities (choose "Keyword search" tab) 3/ copy the 2 new record.abs files (Marc21 auth, Marc21 bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ make the same authorities searches as 2/ : you should get the same results 5/ edit a record to put the value "xxxx" in newly indexed "5XX" field (for example in 530) 6/ search "note:xxxx" : you should find the record 7/ edit a record to put the value "xxxx" in a "5XX" field index in note in addition to a more specifi index (for example in 520) 8/ search "note:xxxx" : you should find the record 9/ in default search (without selecting any index), search for some record by - its isbn - its issn - its title - its author(s) - its series name - its publisher - its summary (520 field) - several subjects - the barcode of one of its items - the callnumber of one of its items => you should find the record each time 10/ in default search (without selecting any index), search for some record by - the content of any 5XX fields (except 502,505,511,520) - the number of pages (ex : "510p") - its language code ("eng", "fre"...) - its publication year - its town of publication - the content of a 05X-08X field - the content of a 010-018 field - the content of a 942 subfield - the content of a 952 subfield (except barcode and callnumber) => you should not find the record each time 11/ regression test : check that specific indexes are working as usual (title, subject, callnum, barcode, pubdate etc) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #20 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- I rewrote the patchs and add test plan. Only for GRS1 for the moment. My Koha VM is a UNIMARC DOM, so I cannot test it myself, but I hope it will work. I made 3 patchs so that somebody can test and sign Marc21 patch and somebody else UNIMARC patch. The list of fields I kept in "any" can be discussed, but once the patch is pushed, each library will have the ability of deleting or adding fields by modifying its zebra conf files. When we all agree on the list of fields to keep, I will make patchs for DOM. M. Saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gmcharlt@gmail.com --- Comment #21 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- I add Galen, as we had elsewhere some discussion about this patch. M. Saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #22 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Of course, in test plan of UNIMARC patch, read "In a UNIMARC GRS-1 Koha" (and not Marc21!) M. Saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #23 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Maybe I could remove the changes made for authorities, as they are not really needed, and create an other bug for improving auth indexing (index coded fields, marc21 notes etc) M. saby -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 I'm just a bot <gitbot@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply CC| |gitbot@bugs.koha-community. | |org When did the bot| |2013-10-30 last check this| | --- Comment #24 from I'm just a bot <gitbot@bugs.koha-community.org> --- Applying: Bug 8962: Unimarc biblios and authorithies (GRS1) Using index info to reconstruct a base tree... M etc/zebradb/marc_defs/unimarc/biblios/record.abs Falling back to patching base and 3-way merge... Auto-merging etc/zebradb/marc_defs/unimarc/biblios/record.abs CONFLICT (content): Merge conflict in etc/zebradb/marc_defs/unimarc/biblios/record.abs Patch failed at 0001 Bug 8962: Unimarc biblios and authorithies (GRS1) The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21986|0 |1 is obsolete| | --- Comment #25 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 22675 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=22675&action=edit [PATCH 3/3] Bug 8962: Unimarc biblios and authorithies (GRS1) rebased -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|9352, 9828, 9830 |11202 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #22675|0 |1 is obsolete| | --- Comment #26 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 23110 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23110&action=edit [PATCH 3/3] Bug 8962: Unimarc biblios and authorithies (GRS1) Patch for unimarc re-wrote. Now depends on bug 11202, which I hope will soon be validated. Mathieu -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 I'm just a bot <gitbot@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- When did the bot|2013-10-30 00:00:00 |2013-11-23 last check this| | --- Comment #27 from I'm just a bot <gitbot@bugs.koha-community.org> --- Patch applied cleanly, go forth and signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 I'm just a bot <gitbot@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply --- Comment #28 from I'm just a bot <gitbot@bugs.koha-community.org> --- Applying: Bug 8962: Unimarc biblios and authorithies (GRS1) Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 8962: Unimarc biblios and authorithies (GRS1) The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff CC| |chris@bigballofwax.co.nz Bot Control|--- |Ignore this bug -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |11291 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #29 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- For DOM, (not written yet) it will depend on bug 11291 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #23110|0 |1 is obsolete| | --- Comment #30 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 23115 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23115&action=edit [PATCH 3/3] Bug 8962: Unimarc biblios and authorithies (GRS1) rebased -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|11291 | Bot Control|Ignore this bug |--- -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #31 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- I've removed the dependency on bug 11291. It was not a "real" dependancy. I just want to wait for bugs 11291 and 11202 being pushed to master before writing the DOM followup for this patch. I also wait for this patch to be tested and signed off with the current indexing style (GRS1) before porting it for DOM. Mathieu -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21985|0 |1 is obsolete| | --- Comment #32 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- Created attachment 23204 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23204&action=edit [PATCH 1/3] Bug 8962: Changes to CCL.properties, bib1 for authorities, and templates -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #23204|0 |1 is obsolete| | --- Comment #33 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 25671 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25671&action=edit [SIGNED OFF] Bug 8962: Changes to CCL.properties, bib1 for authorities, and templates This patch adds a new index Anywhere in ccl.properties in bib1 for authorities, and add "any word" option in intranet search for using this index. Default OPAC and intranet search in still using CCL "Any" index. Testing plan : In a Marc21 GRS-1 Koha : 1/ make some biblio searches without selecting any index (Koha will use "any" index) and note the results. Ex : search "fre", "eng", "book", "history", "history book" 2/ apply the 3 patches 3/ copy the 4 new record.abs files (Marc21 auth, Marc21 bib, Unimarc auth, Unimarc bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ check that a new choice "Any word (all indexes)" is visible in advanced search. 6/ make the same searches as 1/ : you should see less results (detailed test plan in patchs 2 and 3) 7/ in Staff interface adavanced search, select "Any word (all indexes)" and make the same searches as 1/ : you should see the same results (maybe with a slight differences, because more notes fields are indexed in Marc21) In a UNIMARC GRS-1 Koha : same test Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25671|0 |1 is obsolete| | --- Comment #34 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 25672 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25672&action=edit [SIGNED OFF] Bug 8962: Changes to CCL.properties, bib1 for authorities, and templates This patch adds a new index Anywhere in ccl.properties in bib1 for authorities, and add "any word" option in intranet search for using this index. Default OPAC and intranet search in still using CCL "Any" index. Testing plan : In a Marc21 GRS-1 Koha : 1/ make some biblio searches without selecting any index (Koha will use "any" index) and note the results. Ex : search "fre", "eng", "book", "history", "history book" 2/ apply the 3 patches 3/ copy the 4 new record.abs files (Marc21 auth, Marc21 bib, Unimarc auth, Unimarc bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ check that a new choice "Any word (all indexes)" is visible in advanced search. 6/ make the same searches as 1/ : you should see less results (detailed test plan in patchs 2 and 3) 7/ in Staff interface adavanced search, select "Any word (all indexes)" and make the same searches as 1/ : you should see the same results (maybe with a slight differences, because more notes fields are indexed in Marc21) In a UNIMARC GRS-1 Koha : same test Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #35 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 25673 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25673&action=edit [SIGNED OFF] Bug 8962: Unimarc biblios and authorithies (GRS1) This patch depends on Bug 11202 This patch makes some changes UNIMARC GRS1 indexing, for indexing only some specific fields in "any" index. The patch is fully testable, and can be signed off if it works. But the list of fields I kept in "any" is rather subjective, and based as my experience as a library user: It can be discussed in followups. 1. Defines a new index "anywhere" for indexing all biblio and authorities subfields. 2. Make "any" index more selective than before : - for authorities : all fields indexed in any except 001 and notes (3XX) - for biblios : fields indexed in any : * biblio fields indexed in "any" : ** the more "user friendly" control numbers : 01X, 07X ** authors : 7XX except $9, 200$f$g ** titles : 4XX except $9, 5XX except $9, 200$a$c$d$e$h$i ** edition statement : 205 ** series : 225, 410, 411 ** subjects : 6XX except $9 and 67X/68X ** notes : only 327, 328, 314, 330 * items fields indexed in "any" : ** barcode : 995f ** callnumber : 995k Test plan : In a Marc21 GRS-1 Koha : 1/ apply patch 1 and this one 2/ in Staff interface, make some searches on authorities (choose "Keyword search" tab), including searches of words only present in 3XX fields. 3/ copy the 2 new record.abs files (UNIMARC auth, UNIMARC bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ make the same authorities searches as 2/ : you should get the same results, except for searches based on words only present in 3XX fields : in that case, you should not see the auth records. 6/ in default search (without selecting any index), search for some record by - its isbn - its issn - its title - its author(s) - its series name - its publisher - its summary (330 field) - several subjects - the barcode of one of its items - the callnumber of one of its items => you should find the record each time 7/ in default search (without selecting any index), search for some record by - the content of any 3XX fields (except 327,328,314,330) - the number of pages or volumes (ex : "510 p." or "1 vol") - its language code ("eng", "fre"...) - the value of 200$b (like "Texte imprimé") - its publication year - its town of publication - the content of a 670-680 field - the content of a 995 subfield (except barcode and callnumber) - the content of a 099 subfield => you should not find the record each time 8/ regression test : check that specific indexes are working as usual (title, subject, callnum, barcode, pubdate etc) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #36 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 25674 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25674&action=edit [SIGNED OFF] Bug 8962: Marc21 biblios and authorithies (GRS1) This patch makes some changes MARC21 GRS1 indexing, for indexing only some specific fields in "any" index. The patch is fully testable, and can be signed off if it works. But the list of fields I kept in "any" is rather subjective, and based as my experience as a library user: It can be discussed in followups. 1. Defines a new index "anywhere" for indexing all biblio and authorities subfields. 2. Make "any" index more selective than before : - for authorities : all fields indexed in any except 001 - for biblios : fields indexed in any : * biblio fields indexed in "any" : ** the more "user friendly" control numbers : 020->030 ** main entries (authors and uniform title) : 1XX ** title and Title-Related Fields : 20X-24X ** publisher : 260$b ** series : 4XX ** some notes : 502 (dissertation), 520 (abstract), 505 (formated content), 511 (participant) ** subjects : 6XX ** added Entry Fields : 70X-75X ** linking Entries-General Information : 76X-78X ** series Added Entry Fields : 80X-83X * item fields indexed in "any" : ** callnumber : 952$o ** barcode : 952$p 3. Also index all the Marc21 notes (5XX) in "Notes" index (same logic as current 3XX fields indexing in UNIMARC) - new fields not indexed before : 504,506,507,508,511,513,514,515,516,518,521,522,524,525,530,533,534,535, 536,538,540,541,542,544,545,547,550,552,555,556,561,562,563,567,580,581,583,584,585,586,588 - fields indexed in "Notes" in addition to a more specific index : 502,505,521,520,510,526 4. Also index all the Marc21 notes (5XX) in "Notes" index (same logic as current 3XX fields indexing in UNIMARC) 5. Adds a lot of comments to make easier further changes and error checking Test plan : In a Marc21 GRS-1 Koha : 1/ apply patch 1 and this one 2/ in Staff interface, make some searches on authorities (choose "Keyword search" tab) 3/ copy the 2 new record.abs files (Marc21 auth, Marc21 bib) from your sources to the directory used by Zebra configuration in your Koha instance 4/ launch rebuild_zebra.pl -b -r -x -v 5/ make the same authorities searches as 2/ : you should get the same results 5/ edit a record to put the value "xxxx" in newly indexed "5XX" field (for example in 530) 6/ search "note:xxxx" : you should find the record 7/ edit a record to put the value "xxxx" in a "5XX" field index in note in addition to a more specifi index (for example in 520) 8/ search "note:xxxx" : you should find the record 9/ in default search (without selecting any index), search for some record by - its isbn - its issn - its title - its author(s) - its series name - its publisher - its summary (520 field) - several subjects - the barcode of one of its items - the callnumber of one of its items => you should find the record each time 10/ in default search (without selecting any index), search for some record by - the content of any 5XX fields (except 502,505,511,520) - the number of pages (ex : "510p") - its language code ("eng", "fre"...) - its publication year - its town of publication - the content of a 05X-08X field - the content of a 010-018 field - the content of a 942 subfield - the content of a 952 subfield (except barcode and callnumber) => you should not find the record each time 11/ regression test : check that specific indexes are working as usual (title, subject, callnum, barcode, pubdate etc) Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #37 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 25675 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25675&action=edit Bug 8962: Marc21 biblios (DOM) This followup adds DOM support (MARC21) to this patch series. The same set of fields are indexed in the 'Any' index as were chosen by Mathieu Saby for GRS-1 setups. An 'Anywhere' index was also added to maintain backward compatability as per Mathieu's patches. Test Plan: As for GRS-1, but with DOM enabled as aposed to GRS-1 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21987|0 |1 is obsolete| | CC| |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #23115|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #38 from David Cook <dcook@prosentient.com.au> --- Comment on attachment 25675 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25675 Bug 8962: Marc21 biblios (DOM) Review of attachment 25675: --> (http://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=8962&attachment=25675) ----------------------------------------------------------------- This looks really good at a glance. I'll have to test this one sometime in the future. I think some of the choices for the new "any" index might be a bit arbitrary, but we can fine tune that over time (or people can customize it as needed). I noticed some Notes fields have been added as well...I assume this is just to bring DOM in line with GRS-1? ::: etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml @@ +874,5 @@
<target_index>Subject:w</target_index> <target_index>Subject:p</target_index> + <target_index>any:w</target_index> + <target_index>any:p</target_index> + <target_index>any:w</target_index>
Looks like you accidentally doubled-up here. @@ +1605,5 @@
<target_index>Local-classification:p</target_index> <target_index>Local-classification:s</target_index> + <target_index>any:w</target_index> + <target_index>any:p</target_index> + <target_index>any:s</target_index>
I actually don't think that we need to use the 'sort' register here, since we don't sort on the "any" index. We need Local-classification:s, because we have 'Call number' sort on the OPAC, but that's the only reason. Probably safe to nix it here. That said, no harm done by including it. It's probably just redundant. http://www.indexdata.com/zebra/doc/administration-ranking.html -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11291 --- Comment #39 from David Cook <dcook@prosentient.com.au> --- Martin, I noticed that you've only done biblios, but I believe that authorities are needed as well. Hmm, the more I look at this...the more I think that it's sub-optimal to pepper "any:w" and "any:p" throughout "biblio-koha-indexdefs.xml". It might make more sense to add <index_any> elements to "biblio-koha-indexdefs.xml" and "authority-koha-indexdefs.xml", and create a new template in "koha-indexdefs-to-zebra.xsl" to create the appropriate XSLTs as necessary. Galen, as it looks like you did a lot of work on "koha-indexdefs-to-zebra.xsl", what are your thoughts on doing it that way? (As a sidebar, I think we could optimize "koha-indexdefs-to-zebra.xsl" a bit more in terms of how templates are applied, but also of the mind "if it ain't broke, don't fix it".) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #40 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Hi David, It's really great someone else is starting to look at this, we found it made a huge difference to search for our customers. My patch simply took mathieu's work through the conversion to DOM process (which jcamins hates me doing ;) ). I'd love to see it 'done right' but at the time, and still now unfortunately, I haven't had the time to really dead the dom configs and understand them enough to write them manually. I also agree that this should probably be done for authorities to, but I hadn't gotten around to it either, as biblios we're my highest priority. I'm all in favour of the plan to nuke the GRS-1 configs completely in favour of using DOM everywhere and therefore only having the one config style to learn. Let me know if I can help with testing any of it.. but at he moment I'm a tad too snowed under to do any real work on coding it myself. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #41 from mathieu saby <mathsabypro@gmail.com> --- I thought I had done something for authorities, or tried. But I can't find bakc (except bug 11191 and bug 11053, but not directly related). Anyway, biblio records indexing can be improved separately, and it is probably more important than authorities. Mathieu -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #42 from David Cook <dcook@prosentient.com.au> --- (In reply to Martin Renvoize from comment #40)
Hi David,
It's really great someone else is starting to look at this, we found it made a huge difference to search for our customers.
My patch simply took mathieu's work through the conversion to DOM process (which jcamins hates me doing ;) ).
I'd love to see it 'done right' but at the time, and still now unfortunately, I haven't had the time to really dead the dom configs and understand them enough to write them manually.
I also agree that this should probably be done for authorities to, but I hadn't gotten around to it either, as biblios we're my highest priority.
I'm all in favour of the plan to nuke the GRS-1 configs completely in favour of using DOM everywhere and therefore only having the one config style to learn.
Let me know if I can help with testing any of it.. but at he moment I'm a tad too snowed under to do any real work on coding it myself.
I just stumbled across it as I was looking for all "Search" bugs to test (since I've been looking at Search so much lately). That said, it does seem like it would be useful! Ahhh, I gotcha. Fair enough about time. I'm about to work on other projects for the day, but I would be willing to look into this one next week probably. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=12872 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #43 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Martin: The first three patches are signed off already, the fourth patch is DOM only. Could we move your fourth patch to a new report and promote this report to Signed off? Note also that patch 2 and 3 are GRS1, to be obsoleted in near future. I am not sure if it still makes sense to put this in master.. Spotted a typo in the first patch: Any world (all indexes) --> word perhaps :) A question on the DOM patch: Any is now a subset of Anywhere, which is good. But I am not sure if everybody wants Anywhere by default (in terms of space, performance or privacy). Could we make it an installation choice somehow? If Anywhere should not be there, should we still do something to let Any be its fallback? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #44 from mathieu saby <mathsabypro@gmail.com> --- Hello If you are interested in improving indexing, you can see Bug 9352 (the 3rd patch introduces a new logic for grouping subfields), and bug 9828 Mathieu -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #45 from David Cook <dcook@prosentient.com.au> --- (In reply to M. de Rooy from comment #43)
Martin: The first three patches are signed off already, the fourth patch is DOM only. Could we move your fourth patch to a new report and promote this report to Signed off? Note also that patch 2 and 3 are GRS1, to be obsoleted in near future. I am not sure if it still makes sense to put this in master..
Spotted a typo in the first patch: Any world (all indexes) --> word perhaps :)
A question on the DOM patch: Any is now a subset of Anywhere, which is good. But I am not sure if everybody wants Anywhere by default (in terms of space, performance or privacy). Could we make it an installation choice somehow? If Anywhere should not be there, should we still do something to let Any be its fallback?
Those are all really good questions. After reviewing the patches a bit more, I don't think it actually makes sense to even add "anywhere" to GRS1, as it doesn't agree with the Bib-1 semantics (http://www.loc.gov/z3950/agency/bib1.html). The "Any" index/register should contains all the data contained in all the other indexes/registers (e.g. Title, Author, Subject, etc). [Note: this is how it currently is set up to work.] The "Anywhere" index/register should contain the entire record including fields/subfields that aren't indexed anywhere else. [Note: while this is possible using DOM, I'm not sure that it is possible with GRS1. Even if it is, since we're deprecating it, it becomes unnecessary.] It probably would be a good idea to make inclusion of Anywhere configurable (in terms of space, performance, and privacy). That's a really really really good point. How to do that though... that could be trickier. When using DOM, we could disable Anywhere by default, and then say to run something like the following: "xsltproc koha-indexdefs-to-zebra.xsl {biblio,authority}-koha-indexdefs.xml > {biblio,authority}-zebra-indexdefs.xsl --stringparam anywhere index" We would just need to add a xsl:param for "anywhere" into the koha-indexdefs-to-zebra.xsl. As for having "Any" be the fallback of "Anywhere"... you might be able to do something tricky in ccl.properties using aliases, but I'm not sure. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #46 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Wow there suddenly been allot of movement on this and related bugs! It was my feeling that, at the time of writing the DOM follow-up, all indexing related bugs should be written to account for both DOM and GRS1 (We had real issues with the two configs falling out of sync very often). However, with the imminent complete deprecation of GRS1 I'd actually prefer to see Patch 1 and 4 (and a patch 5 with Unimarc for DOM) end up as the final set. Anywho, that's enough history. As for Davids comments, I'm not Zebra spec expert, but it was my belief at the time that the Any Index was in fact a wholly inclusive index and was therefore not especially useful, hence being very interested in a narrowing down of the fields present within it. As for the Anywhere index, it sort of made sense at the time, basically to prevent a regression. I personally don't think it's a useful index, but that's just an opinion ;) I'm gonna go read Mathieu's related bugs now.. see what they do and try to work out whether they're supplementary or as a posed to this bug. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bgkriegel@gmail.com Status|Needs Signoff |Patch doesn't apply --- Comment #47 from Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> --- This no longer applies CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/includes/search_indexes.inc Also GRS-1 is deprecated -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 mathieu saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mathsabypro@gmail.com |gmcharlt@gmail.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 --- Comment #48 from mathieu saby <mathsabypro@gmail.com> --- Hello I won't be able to work on that bug anymore. Feel free to take my patches as a base for further work if you think they can be useful. Mathieu -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Indranil Das Gupta <indradg@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |indradg@gmail.com -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org