I could see continue exposing it in "Expert Search/MARC Tag search" where it is expected. Maybe it already is doing it? I haven't tested it.
On Mon, Sep 29, 2014 at 1:38 PM, J. Sara Paulk <[email protected]> wrote: > > From a non-programmer, but one who catalogs - could the Matches Exactly > be available for advanced or expert searching? Sometimes, you really DO > need to search in the most narrow way possible. > > >> On Mon, Sep 29, 2014 at 1:13 PM, Kathy Lussier <[email protected]> >> wrote: >> >>> Hi all, >>> >>> I wanted to float an idea to the community. I spent a little time this >>> morning looking at a bug submitted earlier this year regarding the Matches >>> Exactly search option in the advanced search screen - >>> https://bugs.launchpad.net/evergreen/+bug/1267129. After thinking about >>> the problem, I came to a conclusion that I've drawn on similar occasions >>> when looking at previous problems with exact match searching that has since >>> been fixed. Overall, I think this search option along with, to a lesser >>> extent, the Starts With search option, is more likely to cause frustration >>> for users than to solve any search problems. >>> >>> I'm curious to know if others have found the same problems in their >>> libraries and, if so, if there is any willingness in the community to >>> remove those options in the advanced search screen to save frustration on >>> the part of users. >>> >>> My reasons for removing them are below: >>> >>> 1. The intent of this search option is to perform a left- and >>> right-anchored search on the search terms. The entered search terms need to >>> exactly match the index as it appears in the relevant metabib table. If >>> doing a title search, you need to enter the entire title including 245a and >>> 245b. I believe most users are unlikely to know what the subtitle is for a >>> book and a. The re more likely to enter just the words that are in 245a. >>> >>> 2. Right now, there is a bug with Matches Exactly. As of now, if you >>> enter the following terms in the search box: >>> >>> the joy of cooking >>> >>> the system will retrieve anything that begins with "the", ends with >>> "cooking" and also contains the words "joy of" in no particular order. I >>> just conducted a matches exactly search for the help today and, in addition >>> to retrieving "The Help" it also retrieved a record for "The Berenstain >>> Bears hurry to help." The fix for this particular issue is fairly easy, but >>> the fix also means that the Matches Exactly will become even more >>> unforgiving than what I outlined in #1 above. Punctuation will matter more. >>> In addition to entering all of the words in the 245a and 245b, the user >>> will also need to know where to add punctuation. From what I can tell, this >>> isn't consistent for all punctuation. In looking for the title "The assist >>> : hoops, hope, and the game of their lives" the following search works: >>> >>> "^The assist hoops, hope, and the game of their lives$" >>> >>> but these searches do not work: >>> >>> "^The assist : hoops, hope, and the game of their lives$" >>> >>> "^The assist hoops hope and the game of their lives$" >>> >>> It looks like the user needs to know that the colon should be removed, >>> but the commas should remain. >>> >>> 3. The "Starts With" search is a little more forgiving since a user is >>> more likely to know the start of a title rather than the entire string, but >>> it still suffers from the problems of a user needing to know what >>> punctuation should be entered (or not entered) for the string that they >>> type. Since it is a search that uses left-anchoring, it also does not >>> ignore non-filing indicators, which is something that users sometimes >>> expect it to do. Note: I was the person who added the "Starts With" search >>> to Evergreen, mainly as a way to ameliorate the issues we saw with the >>> "Matches Exactly" search. Now that Browse search is available in the >>> catalog, I don't think this particular search is necessary on the advanced >>> search screen anymore. >>> >>> 4. In a standard Evergreen installation where no custom indexes have >>> been added, both of these search options will probably fail for a keyword >>> search. This happens because, by default, there is one keyword index (the >>> blob) where all of the indexed terms for the record are stored, and there >>> is no way any user could know all of the terms that are stored there and >>> their proper order. If they are entering a title, they are more likely to >>> have successful Starts With keyword searches because the title seems to be >>> the first thing that starts off the blob, but if the user were entering any >>> other terms (author's last name?) for a Starts With keywords search, the >>> search will fail. >>> >>> Rather than present a search option to our users that has a higher >>> likelihood of leading to unsuccessful search results than our other search >>> options, I would like to see if there is willingness in the community to >>> remove these options in the next (March/April) release of Evergreen. >>> >>> Please feel free to share any feedback you have to this idea. >>> >>> Thank you! >>> Kathy >>> >>> -- >>> Kathy Lussier >>> Project Coordinator >>> Massachusetts Library Network Cooperative >>> (508) 343-0128 <%28508%29%20343-0128> >>> [email protected] >>> Twitter: http://www.twitter.com/kmlussier >>> #evergreen IRC: kmlussier >>> >>> >> >> > -- > J. Sara Paulk, Director > Houston County Public Library System(478) 987-3050 x 26 > Fax (478) 987-1862 > **Temp location for renovation*** > 1530 Sunshine Ave., Perry, GA 31069 > [email protected] http://houpl.org/ > > -- Tim Spindler [email protected] *P** Go Green - **Save a tree! Please don't print this e-mail unless it's really necessary.*
