Re: [Koha-devel] what about creating a new "opac-any" index in zebra
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. 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. -- Linda Culberson lculber@mdah.state.ms.us Miss. Dept. of Archives and History Archives& Records Services P.O. Box 571 Jackson, MS 39205-0571 Phone: (601) 576-6873
Linda a écrit :
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 ? 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...)
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 :( Regards, Mathieu -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
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@cpbibliography.com (web) http://www.cpbibliography.com/
Jared, On 10/24/2012 10:32 AM, Jared Camins-Esakov wrote:
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@cpbibliography.com <mailto:jcamins@cpbibliography.com> (web) http://www.cpbibliography.com/
Thanks for the clarification. This is great news about the indicators. -- Linda Culberson lculber@mdah.state.ms.us Miss. Dept. of Archives and History Archives& Records Services P.O. Box 571 Jackson, MS 39205-0571 Phone: (601) 576-6873
participants (3)
-
Jared Camins-Esakov -
Linda -
Mathieu Saby