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.

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.

Right now in Primo Central Index the customer can either activate or not a resource. But sometimes more granularity would be appreciated. Namely adding a filter by resource type allowing inclusion or exclusion in the index would be very useful. Please note: it's not a matter of adding a resource type in PCI. It's a matter of excluding records with a specific resource type from activated resources.

For example, some resources/data sources contains not only articles, but also journals and other resource types we actually catalogue. Since right now dedup does not work between local records and PCI, this ends up leading to a lot of duplicated entries in the search results (1 for the journal in the catalogue + 1 for the same journal in PCI).
Allowing us to exclude Journals from PCI, thus having only articles, would greatly reduce noise and bias in the search results.

We would like Austlang (Australian language) codes added to the out of the box language code and mapping tables in Primo and for this coding to map to language facets and language display without any additional intervention by institutions. These language codes, used by many Australian libraries, are recorded in the 041$a field(s) of the bibliographic record. These codes do not conform to the three alpha character coding found in ISO639-2 or 639-3. Australian libraries would expect to use these codes in addition to the standard language coding currently available.
The full list of Austlang codes can be downloaded from : https://data.gov.au/data/dataset/70132e6f-259c-4e0f-9f95-4aed1101c053/resource/e9a9ea06-d821-4b53-a05f-877409a1a19c/download/aiatsisaustlangendpoint_001.csv.

In the brief and full display pages, libraries can display information contained in data fields (such as the title, author, and creation date) from the source record. This information helps users to differentiate records quickly. In some cases, there can be a lot of information that is displayed. This is particularly the case when Contributor is added: all 7XX fields are added, and in their entirety (see for example in the attached screenshot).

We would like an option that would allow the library to either limit the number of fields to display (for example max 3 7XX fields) or to only display fields based on the content of some subfields (for example: only display 7XX where $$e equals 'editor', 'publishing director ', 'translator', 'Director', 'film director'...).