[Koha-devel] what about creating a new "opac-any" index in zebra

[Jared Camins-Esakov]

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) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20121024/18e1f9ef/attachment-0001.htm>