Add a true "exact" search to Advanced search type
The available search types do not include a true "exact" search, where the results inlcude the query term(s) and only the query term(s). This type of search is very useful for one-word queries, especially when it is a common word. Using "begins with" in these situations can still result in dozens of results. We can construct a search, but it's not something the average user would know how to do, e.g.:
Title begins with intervention
Title begins with intervention?
This is a convoluted construction, and we'd prefer a true "is exactly" search type.
The problem with FRBR is not limited to advanced search *, by the way.
Patron clicks on library facet 'Basel Uni – Anglistik', which has _one_ hit.
Instead of _one_ title, he gets '4 versions found', and after clicking again he has to scroll past 3 works that are not in his library.
That's really bad UX.
* where it should just be deactivated in my opinion
Edit 22.4.2021: link in example shows one hit at the moment, because FRBR is turned off in our view. This is what we would like to see.
NERS 6693, open for voting now.
> the need to differentiate between a "is exact"-search and a ... "true exact"-search
We're not talking about two kinds of search.
The problem is that there is a setting in Advanced search _called_ 'is exact', but there is no way to actually DO an exact search, not even by ISBN.
As a feeble workaround to the missing exact search, please consider voting for
Allow patrons to disable FRBR + disable FRBR in advanced search
Did not make it through the second round of NERS.
Second round of Primo NERS voting open now, until 31.8.2020.
Laura Akerman commented
The effect of this from the few tests I've done - is that for a single word search the results for "Is (exact)" are the same as "contains". If Ex Libris intended to offer an Advanced search type for a phrase search, they should label it "Contains phrase" (although I think most users know how to use the quote marks - they learned from Google). My first impulse is, "this type of search isn't working, we should put in a SalesForce case". If Primo can no longer execute this kind of search for some reason, I hope Ex Libris will let us know and change the labelling on that search type. But true Exact search is really what we need!
Katharina Wolkwitz commented
I guess there is always a chasm between what librarians expect from a "search type" definition and what any kind of user might expect. ;-/
I'm very new to Primo - we're still in the deployment phase, but being confronted with the need to differentiate between a "is exact"-search and a hopefully to be developed "true exact"-search (a feature that offers itself up to be hidden as a kind of "easteregg" for the iniated ;-) or very needy librarians ;-) ) reassures me that ExLibris is keeping true to form.
I've "only" had expierence with Aleph so far (but that for quite some years) since version 14 till now on 22. We're going over to Alma from next year on.
When I search for 'ISBN - is exact - ..." I should only get hits with this exact ISBN, without the rest of the FRBR cluster.
Norman Howden commented
The functionality should include handling of hyphenated words and contractions.
Norman Howden commented
Good grief - this isn't already in the product???
Yes, I agree. This is absolutely necessary in Primo. The way it behaves now, is not good enough, and it is confusing to users.
At least, the option should be given, to include or exclude related results.
Blake Galbreath commented
Yes, it would be great if the "Exact" search would exclude records with strings outside of the matched query. That would be different functionality. It seems to me that the current design simply recreates a "Contains" search with the query in quotation marks.
Stacey van Groll commented
I should add as well that I'm aware that such a precise 'only' exact phrase search will drastically limit results returned, especially given the great deal of variation with PCI citations in different collections. In many cases, this is the actual end goal, but it is worth noting. For us, with our Advanced Search usage at around only 8-9% of all searches, I would argue an expectation that users deliberately going to a search titled as 'Advanced' and selecting exact phrase have a greater level of understanding, tolerance and indeed requirement for the need for precision, and that this is exactly the type of user which this enhancement would support.
Martha Gunnarson commented
Please add for VE as well, and Alma, while you are at it!
Stacey van Groll commented
We have also noted this undesirable behaviour, of Advanced Search ‘exact phrase’ also including metadata outside the specified phrase.
As an example, if I choose to do an Author/Creator search by exact phrase for: Marshall Green
I expect to see results returned where the search PNX creatorcontrib fields have precisely just: Marshall Green
Instead, I also see additional results such as: Lydia Marshall Green
<creatorcontrib>Green, Lydia Marshall</creatorcontrib>
<contributor>Lydia Marshall Green (Firm) (Corporate Author)</contributor>
The OLH describes the exact phrase search as follows:
"is (exact) – Returns results that contain phrases that exactly match the phrases specified in the query."
This means that currently ‘exact phrase’ is behaving as described and this is not a bug, but I believe that users actually expect the behaviour to be as follows:
"is (exact) – Returns results that contain phrases that exactly match the phrases specified in the query, and only those phrases."
Andrew Welch commented
I should add that we would like this functionality in both the classic UI and new UI.