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