In UNIMARC configuration, there are some complaints from Zebra about non existing indexes: > 21:12:42-22/10 zebraidx(29295) [warn] Index 'UPC' not found in attset(s) > 21:12:42-22/10 zebraidx(29295) [warn] Index 'Serials' not found in attset(s) > 21:12:42-22/10 zebraidx(29295) [warn] Index 'Printed-music' not found in attset(s) > 21:12:42-22/10 zebraidx(29295) [warn] Index 'Electronic-ressource' not found in attset(s) > 21:12:42-22/10 zebraidx(29295) [warn] Index 'Title-host' not found in attset(s) > 21:12:42-22/10 zebraidx(29295) [warn] Index 'title-host' not found in attset(s) > 21:12:42-22/10 zebraidx(29295) [warn] Index 'lcn' not found in attset(s) Those indexes should either be removed from record.abs or created into bib1.att/ccl.properties Mathieu suggested the following options, that are worth being followed: I think I would try this : *** UPC : melm 072$a UPC:w,Identifier-standard:w melm 072$z UPC:w,Identifier-standard:w In MARC21, it is in 024, alongside other identifiers (the indicator of the fields precise the nature of the identifier, but of course record.abs cannot take that into consideration...) So UPC is only defined in UNIMARC, whereas it is an id kind of EAN, used mainly in the USA and Canada, MARC21 countries. That's not logical. This index is useless for UNIMARC ppl, especially if it is not working well. => my proposition: get rid of UPC in UNIMARC conf files and index 072 in "Identifier-standard" and in ccl.properties If marc21 ppl want to index this in their DOM conf file, they will create the propoer custom definition in ccl and bib1.att. *** Serials and Printed-music melm 207 Serials,Serials:p melm 208 Printed-music,Printed-music:p 207 field is equivalent to 362 field in MARC21 208 field is equivalent to 254 field in MARC21 http://www.loc.gov/marc/unimarctomarc21_2xx5xx.pdf Both are not indexed in MARC21, so maybe the information is not really important. BNF sites give some examples http://multimedia.bnf.fr/unimarcb_trad/B207-6-2010.pdf "Cette zone contient les numéros de la première et de la dernière livraison de la ressource continue et/ou les dates que couvrent ces livraisons quand ces numéros et ces dates sont connus." Ex : "Vol. 1, no. 1 (1 Apr. 1946)-vol. 26, no. 195 (10 Oct.1972) = no. 1-no. 6943 " => for me, this field should NOT BE indexed in any way! http://multimedia.bnf.fr/unimarcb_trad/B208-6-2010.pdf "Cette zone contient une mention, transcrite à partir de la ressource, relative à la présentation particulière d'une ressource musicale imprimée ou manuscrite. " Ex : "Partition de poche" Maybe it can be usefull, and I did not find declarations for that in ccl or bib1, so let's create a custom one, OR maybe index it in notes. *** Electronic-ressource melm 230$a Electronic-ressource Electronic-ressource : 230 is deprecated in UNIMARC. Maybe present in legacy records, but not sure of that. Let's get rid of this index. *** Title-host melm 461$t Title,Title-host:w,title-host:p title-host : typo for Title-host 461: Title-host: as we have 461$9 indexed in "Host-Item-Number", I guess this "Title-host" is a mistake for "Host-item". So, 461 would behave like 773 in MARC21 (Technically, 461 is not a strict equivalent of 773. From LOC site, I get that the official equivalent of 461 in MARC21 is 774) *** lcn lcn isn't used
I was writing a new bug, but did not validate the form ;-)
in fact lcn is an alias for Local-Classification (for 995k) I removed lcn from record.abs, but forgot to do it for the 2 new DOM conf files. The more simple for 208 is probably to index it in notes. If you or some Biblibre guy write a patch, I could easily test it and sign it off for DOM Unimarc (current conf of my VM) Mathieu
Created attachment 22303 [details] [review] Bug 11119 silent zebra in UNIMARC This patch fixes some zebra configuration mistakes in UNIMARC, that results in many warnings issued on zebra console Test plan: * run a search with zebra, see that there are lot of warnes like : 23:32:56-22/10 zebrasrv(1) [warn] Index 'lcn' not found in attset(s) * apply the patch * update your zebra config file, reload zebra (no need to reindex afaik) * run the same search => no more warnings Changes: * UPC (on 072$a & $z) has been removed * Serials, Printed-music & Electronic-ressource has been removed * Title-host has been replaced by Host-item * lcn has been removed
Mathieu: additional comments: * Host-item is also defined in 995$a => seems silly to me. Do you confirm ? (I haven't changed anything in this patch) * all 4xx$t fields are indexed as Title. Isn't it wrong ? (Sounds strange to me)
(In reply to Paul Poulain from comment #4) > Mathieu: additional comments: > * Host-item is also defined in 995$a => seems silly to me. Do you confirm ? > (I haven't changed anything in this patch) I never used analytics, so not sure of how it is working. In MARC21, is the equivalent of 995$a also indexed in "Host-item"? If not so, it is probably a mistake in Unimarc. > * all 4xx$t fields are indexed as Title. Isn't it wrong ? (Sounds strange > to me) I suppose it could be usefull for some of them, maybe for all. For ex, if you have a serial whose name has changed, the old name will be in 4XX. And a user could find it by searching the old name. Idem, if you have a set of 3 books with a collective title (ex : "French history", with vol. 1 = "From Ceasar to Clovis", vol. 2 = "From Clovis to De Gaulle"), the main title will be in 200$a, and some 4XX will be used to store the title of vol. 1 and 2. See the indexes used in SUDOC network : http://documentation.abes.fr/sudoc/manuels/pdf/index_cles.pdf index MTI (Mot du Titre) Titre 200 $a $c $d $e $h $i Note de contenu 327 $a Titre uniforme 500 $a $h $i $k $l $m $n $q $r $s $u $3 Rubrique de classement 501 $a $e $k $m $r $s $u $3 Titre de forme 503 $a $b $d $e $f $h $i $j $k $l $m $n Tous titres ajoutés 51X $a $e $h $i 520 $a $e $h $i 54X $a $e $h $i Titre clé 530 $a $b Titre développé 532 $a Titres principaux de tables des matières (PROVISOIRE) 359 $b $c Titres en relation 4XX sauf 410 qui va en COL Note that the Sudoc is also indexing 359 (table of contents). This field is - I think - typically french. It is not in Zebra standard unimarc conf files yet. Mathieu
For 773 and 461 : they are used in C4::Biblio::PrepHostMarcField, respectively for Marc21 and Unimarc. Confirmation that they are equivalent fields. (By the way, C4::Biblio::PrepHostMarcField seems more written in Marc21 than in Unimarc) Mathieu
Paul, I think you forgot to add ../unimarc/biblios/biblio-zebra-indexdefs.xsl to your patch. Could you regenerate it from ../unimarc/biblios/biblio-koha-indexdefs.xml ?
Applying: Bug 11119 silent zebra in UNIMARC Using index info to reconstruct a base tree... M etc/zebradb/marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml 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 Auto-merging etc/zebradb/marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml CONFLICT (content): Merge conflict in etc/zebradb/marc_defs/unimarc/biblios/biblio-koha-indexdefs.xml Patch failed at 0001 Bug 11119 silent zebra in UNIMARC 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".
Hello Paul I believe you regenerated DOM files from record.abs. This is maybe not a good idea, as the different files have now to live their own lives... I am writing a patch with a lot of little changes, I will include inside it the changes discussed here ;-) Mathieu
(In reply to mathieu saby from comment #9) > Hello Paul > I believe you regenerated DOM files from record.abs. This is maybe not a > good idea, as the different files have now to live their own lives... > I am writing a patch with a lot of little changes, I will include inside it > the changes discussed here ;-) > > Mathieu Shouldn't we close this one and mark it as a duplicate of your patch then ? ( I'm fine with it )
yes ;-) *** This bug has been marked as a duplicate of bug 11202 ***