Primo VE is configured to map 6XX $v form subdivisions to a separate display field, breaking the subject string. In some cases, the form subdivision is plucked out of the 6XX, leaving the surrounding string incomplete. For example:

600 10 $aO'Keeffe, Georgia, $d1887-1986 $vExhibitions
displays in Primo VE as:

Subject O'Keeffe, Georgia, 1887-1986

Genre Exhibitions

651 #0 $aRome (Italy) $vMaps $vEarly works to 1800
displays in Primo VE as:

Subject Rome (Italy)

Genre Maps
Early works to 1800

And so on, for all 6XX $v form subdivisions. This cannot be reconfigured. Additionally, each occurrence of the form subdivision is displayed as a separate genre. An exhibition catalog with three artists appearing in 6XX fields would result in three genre term displays, all saying "Exhibitions".

To preserve our subject string with form subdivisions intact, we were advised to consider adding a 9XX with the field as we want it to display and labeling that as Subject in Primo VE.This adds steps to cataloger workflow and generates unnecessary data in the records.

This display feature should be reconsidered. Whether or not to split $v form subdivisions should at least be configurable by libraries.

An institution owns a specific edition of a book, ex:https://bibsys-almaprimo.hosted.exlibrisgroup.com/primo-explore/fulldisplay?docid=BIBSYS_ILS71566408110002201&context=L&vid=SSHF&search_scope=default_scope&isFrbr=true&tab=alle_bibliotek&lang=no_NO

When extending the search scope to other libraries, they may find other editions of the book, which they don’t own (https://bibsys-almaprimo.hosted.exlibrisgroup.com/primo-explore/fulldisplay?docid=BIBSYS_ILS71566408110002201&context=L&vid=SSHF&search_scope=blended_scope&isFrbr=true&tab=alle_bibliotek&lang=no_NO ).

The original/owned book's barcode is shown for the other edition(s) as well. This is unfortunate as it is quite confusing (contradictory messages, give the impression the library owns resources it doesn’t), and can lead the user to order the wrong book.

The availability status is correct but the holdings information is not. The ISBN should be used here to prevent tis from happening, instead of the holdings being based on the title only.

According to Ex Libris (#00628723), this is by design: " this issue is indeed connected to the FRBR-grouping of the two records - because they are FRBR-grouped, you can see the items for both records in each of them".

The only solution is to disable the FRBR-grouping. This is not an option for us to have it disabled in the local index, so we are hereby suggesting that another solution be found, preventing the problem described here, while having FRBR-grouping enabled.

A multi-part resource (eg: a sketchbook containing 200 drawings) is catalogued in MARC 773 (host/item relationship). PrimoVE ought to sort and display the component parts using $$g and $$q. Currently PrimoVE fails to do this in the correct numerical order. Rather, the presentation is alphabetical which is useless for component-items organized by their part or page number. There was a recent ideas exchange issue raised on this very topic, which was “solved” by providing the aforementioned “alphabetical solution”. However, a NUMERICAL visualization has much more value in Discovery for patrons who are interested in locating an item as part of a host (the drawing on page number 12 of a sketch book, for example). This is a frequent and conventional library requirement for example in Special Collections communities, as it reflects accurately the sequential order within an actual work or a manifestation.
Currently (SEE SCREENSHOT BELOW) the user sees this rather wild presentation in PrimoVE (the resource is the sketch-book of 200 drawings cited above).

Another example from the world of monographs is a collection of Brecht’s works: currently looking like this in PrimoVE:

https://basel.swisscovery.org/permalink/41SLSP_UBS/1hbnn2v/alma993707790105504

The publisher’s website displays the correct sequence:

https://www.suhrkamp.de/werkausgabe/bertolt-brecht-werke-grosse-kommentierte-berliner-und-frankfurter-ausgabe-30-baende-in-32-teilbaenden-und-ein-registerband-leinen-w-17

I do not consider this request an “enhancement” feature, rather a basic library requirement, dating back to the traditional card-catalogue-era.

Many thanks.

The open discovery of the new UI allows customers to customize the new UI, extend its functionalities, and connect Primo with external services.
This framework can offer an important added value to institutions; it can enable them to respond to specific needs of their user community.
We want to implement extensions for functionalities like:
• Offer a button “report a problem” that allows a user to report a broken link or another problem with a specific source he found. The form sends this message to our helpdesk, together with useful debug info like : is the user on or off campus, browser version used, search query, pnx-id,.. and his e-mail address when he is signed in. Our e-resources staff finds this functionality extremely useful: more linking issues are reported now and they can be handled in a more efficient way.
• Offer a button “Pay fines” that allows a user to pay fines online. The button is only displayed when the user has fines.

These are extensions that we currently implemented in our old UI.
But creating extensions that make use of session data (like user email, vid, …) are time consuming and risk full:
• Time consuming because documentation is limited not to say non-existing, this requires reading the code. It has a high maintenance cost since after every release, extensions can break and it is difficult to find out why because of the lack of clear release notes.
• It is risk full because we don’t know whether we will be able to fix the functionality in the two weeks between release on staging and production. It is also risk full because we don’t know if the extensions will still work after the transition to Angular 2.

Our request is :
Please provide us with session data in every component so we can quickly create components.
One way to make the extensions manageable and future proof, is to use a data model (see primo-explore-dom). If the data is framework agnostic it will become more portable and working with data is easier and almost timeless.
This way everybody can develop within the reach of their skillset and more institutions would be able to take profit of the open discovery framework.
But we are open to any solution to overcome the issues mentioned.

FRBR groups and the display of versions within them does not consider the relevancy of the terms searched. Often a user is searching for a specific version within the FRBR group (ex: Homer's Iliad translated by Richmond Lattimore) but there is no way to focus in on this version within the list of FRBR versions. Even when users search specifically for terms: Iliad Lattimore, Lattimore is hidden within search results. Within the list of FRBR versions, sorting by Relevancy should use the terms searched by the user -- this should enable the works of a single translator (like Lattimore) to rise to the top of the list of results when that translator's name is explicitly included in the search, greatly improving discoverability and access.

In a consortial Alma setup with a Network Zone and with Primo VE, our consortia has noticed that if an Institution Zone (IZ) has enabled dedupe/frbr in a Primo View and there is print and electronic inventory for a title, the print inventory of other IZ’s is completely hidden and only the electronic displays.

See “enabled dedupe frbr1.png” https://wrlc-gwu.primo.exlibrisgroup.com/discovery/search?query=any,contains,doing%20bayesian%20data%20analysis%20a%20tutorial%20with%20r%20jags%20and%20stan&tab=WRLC_P_MyInst_All&search_scope=WRLC_P_MyInst_All&vid=01WRLC_GWA:test&offset=0

As you can see in “enabled dedupe frbr2.png” only the electronic inventory displays.
https://wrlc-gwu.primo.exlibrisgroup.com/permalink/01WRLC_GWA/1b1hkge/alma9912376416404101

Compare with an IZ in the same consortia which has disabled dedupe/frbr to prove that physical inventory exists.

See “disabled dedupe frbr1.png”
https://wrlc-amu.primo.exlibrisgroup.com/discovery/search?query=any,contains,doing%20bayesian%20data%20analysis:%20a%20tutorial%20with%20R,%20JAGS,%20and%20STAN&tab=WRLC_P_AU&search_scope=WRLC_P_AU&vid=01WRLC_AMU:prod&facet=rtype,include,books&lang=en&offset=0

See “disabled dedupe frbr2a.png” and “disabled dedupe frbr2b.png”
https://wrlc-amu.primo.exlibrisgroup.com/permalink/01WRLC_AMU/1sph5q5/alma9911540263904101
https://wrlc-amu.primo.exlibrisgroup.com/permalink/01WRLC_AMU/1sph5q5/alma9911217900204101

=============================================

Desired behavior: When dedupe/frbr is enabled, display both physical and electronic inventory. Do not hide the print inventory of other IZ’s in favor of electronic inventory.

See “desired behavior.png”
https://wrlc-gwu.primo.exlibrisgroup.com/permalink/01WRLC_GWA/d5n44s/alma99136545603604107

In the above example, both physical and electronic inventory display. George Washington University has physical inventory in its IZ which displays with physical inventory of another IZ, George Mason University alongside electronic inventory.

Salesforce cases (may be unpublished) to reference: 00795991, 00820965, 00807971

-Marcus

Primo Central grouping is based on the existing FRBR workflow, including the grouping process at the database level (the way the Search engine handles grouping) and the Front End functionality. It is used to prevent duplicate records in the results list.

Unfortunately, many records are not added to FRBR groups because the system considers the metadata are not rich enough. With the increase of records provided by (Open Access) aggregators and repositories, the number of duplicate records will certainly not decrease.

Could Ex Libris improve the FRBR workflow for Primo Central records in order to reduce the number of duplicate results and consolidate the FRBR groups?

Examples of duplicate records:
Accuracy of prediction of gene content in large animal populations and its use for candidate gene detection and genetic evaluation
3 results (2 FRBR groups):
- TNproquest195858157 and TNfaoagrisUS201300875183
- TNcrossref10.3168/jds.2007-0231, TNscopus2-s2.0-42449094585, TNsciversesciencedirectelsevierS0022-0302(08)71293-1, TNmedline18349258
- TNorbi2268/23076

Linguistic symbiosis between event loop actors and threads
2 results (1 FRBR group):
- TNsciversesciencedirectelsevierS1477-8424(08)00024-9
- TNscopus2-s2.0-51649125887 and TNcrossref10.1016/j.cl.2008.06.005

Efficient control of transient wave forms to prevent spreading depolarizations
2 results (1 FRBR group):
- TNarxiv0705.3398
- TNscopus2-s2.0-39649117125, TNsciversesciencedirectelsevierS0022-5193(07)00579-6, TNcrossref10.1016/j.jtbi.2007.11.019, TNmedline18177900

Le traitement de la modalité épistémique dans les traductions françaises de On the Origin of Species de Charles Darwin
3 results:
- TNerudit1038687ar
- TNscopus2-s2.0-85017546223
- TN_proquest1870219718

Primo supports display of See references (not same as See Also) in browse headings, if those cross-references are in the bibliographic data ingested by Primo. There is no capacity to display See Also and Usage info from authority records, which are important so that users understand how and why certain terms, especially subjects, may be used.

We propose that See Also and Usage info display in the Browse headings.

Example headings and See Also and Usage info that does NOT currently display in Primo:

Blacks:

Search also under: subdivision Blacks under individual wars, e.g. World War, 1939-1945--Blacks; and headings beginning with the word Black
Here are entered works on blacks as an element in the population. Theoretical works discussing the black race from an anthropological point of view are entered under Black race.

It's possible this enhancement could be achieved through application of an API that interacts with Library of Congress systems. Display of narrow/broader terms would also be highly valuable.

Hi
We're in a consortium, using Primo VE.

Our first two search scope slots are
– IZ
– NZ plus CDI

It is possible to show a facet 'Other libraries', which shows the libraries outside our own IZ.

But 'Other libraries' can't be customized like a normal facet:
– it can't be displayed only in the search scope slot NZ/CDI without being displayed in the search scope slot IZ
– it can't be separated from the facet Libraries and for example put last in the list of facets
– it can't be collapsed if the facet Libraries is not collapsed

Showing libraries from outside our IZ in the search scope slot "IZ" is too confusing.

So for the moment we are hiding 'Other libraries' altogether. But we would like to show it in the search scope slot "NZ/CDI".

https://basel.swisscovery.org

Primo Central Index contains many records for abstracts of conference papers that have been published in journal issues/supplements.

These records are given the Article resource type in Primo. This confuses users, who when they find these items expect a full-length article instead of a short abstract.

It also creates problems with link resolvers, which attempt to generate article-level links and fail (publishers usually do not provide these abstracts as individual articles).

To fix this, Primo Central should be given a new resource type for abstracts.

The sources for these records are usually large indexes such as Scopus or Web of Science, which already mark these items as abstracts. This would make it easy to reclassify items as the Abstract resource type.