Title browse should index 245s with nonfiling characters twice

Actually, from the IRC logs (around http://irc.evergreen-ils.org/evergreen/2014-05-21#i_100042) we found that the current config.metabib_field definition for alternative title might be too inclusive and is indexing these titles twice, once without the non-filing characters and once with them. So both "the heart sutra" and "heart sutra" from the listed example are indexed and put into browse search.

Ideally, we would want these to be separated and the nfi version used for browse, but the full version indexed for search purposes.

Marking confirmed.

Here's a radical idea. Let's forget cataloging correctness for a moment and think about what's easiest for the user.

How about if we keep the 740 browse indexing the way it is AND do the same for the other title browse indexes?

The downside is we would add more entries to the table. The upside is that users would find the correct title whether or not they enter initial articles in the search. We could then get rid of that prompt reminding them to enter initial articles and it would be one less thing to train patrons on when they use the catalog.

Indexing both versions was my suggestion regarding all fields with NFI capabilities at the time of development for exactly the reasons that Kathy lists, but it was rejected because the value would be listed twice, though normally in far-separated locations, in the browse output. I am still in favor of this approach.

NOBLE strongly supports this approach -- what difference does it make if the value is listed twice if it means that the user always finds it where they logically would expect to find it? Few of our users have any experience (at least any recent experience) using print resources where this "drop the article" convention made sense.

There are also issues with articles in other languages. The student checking the library for a recording of "Die Fledermaus" doesn't necessarily know that "Die" in this context is a German article.

So, just to clarify, the 740s are being added to the title browse both with and without the nonfiling characters, which seems pretty helpful both for catalogers and patron users. The 245s are only being added without the nonfiling characters.

So, should this bug shift a bit and change to "titles from 245 fields should be included in the title browse both with and without the nonfiling characters"?

I do think this is a good idea for user discovery. My only concern would be if having so many more entries in the table would negatively impact search retrieval times?

+1 to Jane's question. I also share Elaine's concern. In my testing, browse searches are already much slower than keyword searches. I'm concerned about adding even worse response time.

Regarding performance, browse is slower than search because of authority-proxied visibility checking and linked-record counting, two things that search does not have to do. Both of those are performed after the procedure of actually finding the pivot "closest match" value and gathering the "before" and "after" values, which are themselves very fast. In short, more entries in the browse table does not mean a slower browse.

If it isn't going to slow down the search, then I am +1

I just threw a different title on this bug -- feel free to change it to something that better represents the content of this bug discussion.