Mathieu, In my opinion, one of the problems of creating an "opac-any" index in > zebra is that many of the fields and subfileds in MARC are not meant to be > shown to the public, and indexing them confuses things. If they don't > appear in the opac, yet do appear in the search results, the patron is left > wondering why. > > > > Hello Linda > I have given a bad name to my "opac-any". I should have said > "opac-just-the-fields-we-want-to-index"... > In the current record.abs, the index "any" is defined as "all any". So, if > I understand well, all the fields indexed in other indexes (title, author, > subject, notes, Local-number,Identifier-standard,Country-heading, items, > etc etc) > At least this is the way it works in Unimarc. Maybe not in Marc21 ? >
It is the same with MARC21. > So, for example, in my unimarc catalogue, if I search for "fre" in the > opac, I've got *342825 **results, *because it is the code for french > language in 101a field, index in "ln". gasp. > idem if I search for "lc" or "rameau" (equivalent to LCSH in France), or > "texte" > And with fuzzy or autotruncate activated, it is, well..., very very > annoying. > > So my idea was > - to keep the "all any", because it could be usefull somewhere in Koha > perl code or templates > - to create a more specific index, matching only important field, but in > any event NOT matching coded fields and some boring notes... > - to use this index in opac simple search (and maybe in staff interface > simple search but this could be discussed...) > Also, it is important to keep the "all any" because it's part of the Bib-1 standard. (this is just a side note for those wondering why we would have "all any" in the first place) > There is also the problem that Koha doesn't have a way of dealing with > indicators, such as the "traced" or "untraced" in the 490, for example. > For a record that has minimal cataloging it may not be a problem, but with > a fully cataloged record, it would pull up a lot of false results. But that > is just my 2 cents worth - admittedly not worth much, inflation > considered. > > > Completely agree with you for the indicators. I think it is less important > in unimarc, but that would be very useful if Zebra could manage them :( > Good news! This is possible with DOM! We just need to start taking advantage of that functionality. 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-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/