See also https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/41092123-remove-cdi-constant-expansion-of-results

This will only be implemented for PrimoVE, mind you.

It's great that this idea made it through NERS! :-)

I'm curious though how it will end up after ExLibris is through with the development-process.

When I think of the implementation of the "searching for hyphenated key-words" which ended up with a defined dictionary-list of terms instead of a parser that pulls out the hyphens from the entered search-terms I am still suprised at the ingenuity of ExLibris' giving us something matching a request's wording without hitting the meaning behind it...

Made it through NERS 2021, should be possible by May 2023.

The problem with FRBR is not limited to advanced search *, by the way.

Simple search
https://basel.swisscovery.org/discovery/search?query=any,contains,frye%20anatomy&tab=UBS&search_scope=UBS&vid=41SLSP_UBS:live&lang=en&offset=0

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

NERS 6693, open for voting now.

@Katharina Wolkwitz

> 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
https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/42531016-allow-patrons-to-disable-frbr-disable-frbr-in-ad

Did not make it through the second round of NERS.

Second round of Primo NERS voting open now, until 31.8.2020.

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!

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.

Kate

Related:
When I search for 'ISBN - is exact - ..." I should only get hits with this exact ISBN, without the rest of the FRBR cluster.

The functionality should include handling of hyphenated words and contractions.

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.

+1

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.

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.

Please add for VE as well, and Alma, while you are at it!