PCI results respect that a user knows what they want, but help with expansion when necessary, such as by stemming when there are very few results returned by the exact query. A user has autonomy also to target their results with techniques such as quotation marks, Boolean operators, and Advanced Search.

In CDI, expansion is constant, by term inflection applied to all searches, as well as higher recall in general by design. This cannot be prevented by features such as Boolean operators, quotation marks or Advanced Search, and is illogical in conjunction with other features like 'Did you mean'.
Note: It is recognized that these may represent different underlying mechanisms, but it is the user outcome which is key.

Ex Libris states that CDI behaviour "does not affect precision" because of Verbatim Match Boost, which will rank more highly the exact search query, but they have designed this as also meaning "near verbatim", completely undermining this concept.

Use case: If a user searches for ATLA, then they expect only results for ATLA and not atlas. CDI returns 7 of 10 first page results which are clearly returned on the basis of atlas by term highlighting, even at No.1, and yet also offers a "Did you mean: atlas", which barely changes the results when clicked.

Use case: If a user searches for a DOI, then they expect only that specific resource. CDI returns dozens of results with often no indication by term highlighting or snippets to explain why. This is discovered only after a timeconsuming check on the full text to be because the DOI is in the Reference List. There is no clear pathway to the actually correct known item, and this is not consistently fixed just by ranking changes. For example, if we do not hold that article in full text, the user sees dozens of results, none of which are correct, instead of the expected pathway of the Zero results message, using the expansion checkbox, and then leveraging the metadata in the 'No full-text' citation to prefill an ILL form.

This is the opposite of precision.

The design should centre the user and the needs they directly express when entering their search query, allowing the choice to both target their search by the techniques above, as well as giving the option of expanding their search, which is even more important given the larger CDI index.
One option could be returning the expected targeted results matching the user query, and then offering a suggestion similar to a clickable Did you mean or Controlled Vocabulary features, such as: "Results also referencing [query]"

Hi

We switched to Primo VE some months ago and are really missing a call number index that shows all our call numbers, in items as well as in holdings.

https://slidetodoc.com/three-types-of-call-numbers-in-alma-yoel

"Item Call Number – is it in Primo VE search indexes?
• The item call number cannot be added as a Primo VE search index.
• Of the three call numbers only the “Holding Call Number” can be added as a Primo VE search index."

Our call number index is set to "callnumber.4 – Shelving control number call number", our item call numbers are type 4, but they are missing in the call number index.

https://basel.swisscovery.org/discovery/browse?vid=41SLSP_UBS:live

Examples:

https://slsp-ubs.primo.exlibrisgroup.com/permalink/41SLSP_UBS/mmbbsj/alma9920741170105504

No hit in call number index search for
UBH Bc I 50
UBH Bc I 51
UBH Bc I 52

https://basel.swisscovery.org/permalink/41SLSP_UBS/mmbbsj/alma9910081250105504

Can not be found in the call number index under UBH AL VII 42:1993

We know that it can be done in Alma (see screenshot), but we need the function also in Primo.

In addition to the index search, please also index the item call numbers for simple and advanced search.

Primo Name/Title Browse Searches

As frequent Primo users searching for known music items, the Alma Music Users Group would like to propose that Ex Libris create a left-anchored browse search for name/title entries found in bibliographic records. An alphabetical left-anchored browse search is particularly helpful for known-item searches that are often used for music materials and prolific literary authors.

Currently, Primo provides browse search options for names (name portion only ($a,$q,$d)) and name/title headings used as subjects. For prolific authors, it is not unusual to find thousands of name/title headings lumped under the composers or authors name, with “20+ records” displayed adjacent to the heading. The Primo Browse Search options should include an alphabetical left-anchored “browse” listing for all name/title headings found in bibliographic records.

The left-anchored browse name/title index search for authorized access points should include the subfields from the 700 name portion of the heading, as well as subfields from the 700 title portion of the heading ($t, $f, $m, $n, $r, $l, $k, $p, $o, $s), displayed in the order in which the fields are transcribed in the bibliographic authorized heading. The browse name/title index should also include the name/title information from the 100/240 fields, including the subfields from the 240 ($f, $m, $n, $r, $l, $k, $p, $o, $s), displayed in the order in which the fields are transcribed in the bibliographic authorized heading. In the event that the 100/240 combination cannot be included as the left-anchored browse search is developed, it is critical that these fields are added as soon as possible.

In addition to a browse name/title search that retrieves results from the 7xx fields, the subject browse search should include name/title headings used as subject headings found in the 6xx fields.

The browse indexes should display 4XX and 5XX cross-references and public notes such as the 680 found in authority records. Associated name and title strings must be kept together for both indexing and display. The cross-references are critical in helping the user to find items known by various titles in various languages. The 4xx and 5xx displays should be linked to redirect the patron to the appropriate section in the index.

Benefit: Without a left-anchored browse search, there are too many false drops and omissions when searching for materials by prolific authors and composers. The left-anchored browse results in a more focused and complete search result, helping the user to quickly find all items with the same authorized access point.

Attached is an optimal name/title display for the composer Georges Bizet.

In Primo you can activate autocomplete to get suggestions for search-queries based on what the end-user begins to type in the search-box.

We have tested the functionality and see that it could be useful for the end user to get these suggestions. However we see that the suggestions from the central index in some cases are a little strange and that you get suggestions from the entire index and not only the sources the institution has activated. This means that the end-user could get suggestions that gives 0 results.

If you get a suggestion that leads to nothing you will think that it was a bad suggestions and maybe not use the feature again. That reflects badly on the reputation of the system and institution.

We would like that this functionality is changed so that the users only gets suggestions from sources that are activated for search.

This to prevent that the get suggestions that leads to 0 results.

A strong argument for a discovery index compared to a bibliographic database is the incorporation of full text in the index. I have not found an actual number or a percentage how many Primo Central collections are full text searchable. But we all know: it is significant. Since this year all Primo Central searches will always expand to full text.
https://knowledge.exlibrisgroup.com/Primo/Knowledge_Articles/Primo_Central_Full-Text_Searching

The most powerful feature for full text search is proximity.
https://en.wikipedia.org/wiki/Proximity_search_(text)

Aleph was able to support proximity for small hitsets
https://knowledge.exlibrisgroup.com/Aleph/Knowledge_Articles/Proximity_doesn't_work_for_larger_results.

... and Summon has a proximity feature
https://knowledge.exlibrisgroup.com/Summon/Product_Documentation/Searching_in_The_Summon_Service/Search_Features/Summon%3A_Boolean%2C_Phrase%2C_Wildcard_and_Proximity_Searching#proximity

Proximity search is currently not supported nor planned in the Primo/Primo Central roadmap. Although as part of the search engine algorithm the proximity is being calculated and records in which the query words are closer (we call the distance slop) will be rank higher.

It would be great to add proximity operator to the Primo search syntax and to support proximity search in Primo Central.

Primo's browse search "By Library of Congress Call Numbers" includes the call number prefix (holdings record field 852 $k) when generating the browse list. At UGA, we use that prefix for oversize volumes (Folio, Ff), and for a variety of branch locations, special statuses and shelving areas (Juv, Ref, Vet Med, etc.).

As a result, any holdings with a prefix do not show up alongside holdings in the same call number range, essentially hiding many titles from patrons interested in browsing the shelf list. (This would be an issue for staff as well, but shelf list browsing works correctly in Alma.)

Please reconfigure Primo's browse search to ignore (but, ideally, still display) the call number prefix when generating this index.

Hi

We are in a consortium with a fulfillment network.

Which in many cases means that the patrons can not pick which copy of a book they want to order.

While this may make sense as the default (1), it is frustrating for many patrons, myself included.

• When more than one copy is available, I want to be able to decide which one to get
  
• When a book is on loan I may prefer to wait for the copy of my favorite library to come back instead of getting the book from somewhere else

This is especially relevant when I'm in a setting where getting a copy from another library costs me money.

The option 'choose specific item' should be available in the full title display (when logged in). If this is not possible, it could be an option in the patron settings.

(1) Although it leads to an inconsistent display in Primo VE: sometimes the links for ordering are above the call number, sometimes next to it.

The alert functionality is not really functional in a library network with a Network Zone. Users get an alert when a new bibliographic record is created in the Network Zone, but most users don't care about new acquisitions in other institutions. What they want is to be alerted on new acquisitions in their own institution. This means: to get an alert when a new bibrecord is added to the inventory of of their IZ (not only by creating a new record but also by adding a holding or portfolio to an existing record in the NZ).
Our request is to allow for alerts at the institution level in a consortium with NZ.

Currently, the "starts with" functionality is only available for title searching. There are already some posts here about adding it for other fields, like call number and subject, which I support. This post is about the current behavior though. If I choose to search by another field, such as author/creator or subject, then the next dropdown allows me to choose "starts with" even though it's not available, and it immediately switches to a title search. I'd prefer that, if a user has selected a field other than Title, that "starts with" just wouldn't show up at all. If the task at hand is finding something by author, it doesn't make sense to switch the user to a title search. So if I've selected an author search, then I'd only have contains or is (exact) available in the next dropdown.