En los casos en que disponemos de un registro bibliográfico con ejemplares en formato impreso, copia electrónica activada en la "Comunity Zone", y además se ha activado también en Primo Central para garantizar la indexación y la capacidad de recuperación a nivel de texto completo, el registro bibliográfico se visualiza en Primo VE como si fueran dos registros bibliográficos exactamente con la misma información (códigos de barras, signaturas y ubicaciones duplicados).

Según nos dicen desde SalesForce, debido a limitaciones/arquitectura del sistema, no es posible combinar el registro de Primo Central con los registros locales en Alma, lo cual crea confusión entre nuestro personal y usuarios.

Adjunto una copia de pantalla para que lo véais.

Currently, if you select top-level facets one by one (e.g. "Peer-reviewed Journals" then "Full Text Online"), you get different results than if you select both facets at once (using the checkboxes and clicking "Apply Filters".) The first applies a boolean AND and the second applies a boolean OR.

Ex Libris support has confirmed that this intended and expected behavior.

This functionality seems confusing to both our patrons and staff. I think I can see the argument if this occurs within certain other facets (e.g. Resource Type), but because this happens with top-level facets that do not otherwise seem like the same sort of facet (e.g. "Peer-reviewed Journals" and "Full Text Online"), our patrons and staff have been finding this to be unexpected behavior.

Requesting that this functionality be revisited, especially when it comes to top-level facets.

We would like to allow the user to use the Collection Discovery interface also for discovery. Currently, it is only possible to search at the collection level. It is important to enabling a search across all levels of all collections as the user cannot know in which collection/sub-collections to search for needed items.
Following are a couple of user stories:
* We have various collections of photos. We would like to allow the user to search across the various collections and sub-collections for the pictures of the Knossos temple. We have relevant photos in two different sub-collections.
* We would like to allow the user to search across the various collections and sub-collections for the pictures of the Kabara Swamps. We have photos in various sub-collections that are 3 folder levels down from the Collection Discovery Home Page.

Hello.

Our university system is in a consortial configuration of Alma and Primo Back Office.

Currently, we cannot use Alma collections because one university's (local and institution-specific) collections display in all other Primo instances in our consortia. This is problematic and confusing because a collection at University A displays in University B's Primo as if it were University B's collection. But the collection is local and specific to University A only.

The "collections" I'm talking about are described in the following Exlibris documentation: https://knowledge.exlibrisgroup.com/Alma/ProductDocumentation/010AlmaOnlineHelp(English)/040ResourceManagement/050Inventory/050ManagingCollections
https://knowledge.exlibrisgroup.com/Primo/ProductDocumentation/060BackOfficeGuide/060ConfiguringPrimo%E2%80%99sFrontEnd/050Collection_Discovery

We opened Salesforce cases 00636941 and 00708998 and were told by the Exlibris analysts that "No, currently there is not a way to localize the Collection Paths of Collection Discovery collections. This would be an enhancement request"

And "This would be an enhancement request, as suggested in the previous case. We've reviewed this issue and concluded that the option of localizing Collections is not currently available in Primo. We strongly encourage you to submit this as an enhancement via the Idea Exchange portal"

Thank you.

-Marcus

Technically RSS feeds created by Primo are working. But from a content perspective the feed is a mess.

Let's start with the feed header:

Primo delivers <rss version="2.0">
The standard specification are at http://www.rssboard.org/rss-specification . It was published in August 2002. The RSS 2.0 specification is copyrighted by Harvard University and is frozen. Please use RFC 4287 also known as Atom.
https://tools.ietf.org/html/rfc4287
It is simply the better option for may reasons.
http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared

The description of the feed is <title>Records from Primo</title> .
As a user I would like to see my search terms in the feed title - like in the brief result screen in the web interface. At minimum it should be the name of the service where this feed is coming from. The name of software used to create the feed is useless to a reader.

The link to the source is pointing back to the Primo main page with the classic user interface. But that's confusing for institutions using the new user interface!

Let's have a look to a feed item:

A cruical element of RSS feeds is the
<pubDate>Thu, 09 Nov 2017 16:25:22 GMT</pubDate>
The specification says: "Its value is a date, indicating when the item was published." In a Primo feed this is always the same date; I assume it is the time stamp when the feed was created. Please change this immediately. RSS management software cannot handle it because the pubDate is used for chronological sorting and to find out what's new. What's needed is the publication date of the publication or second best the date and time when the record was added to the Primo index.

The delivered link in the link field is "the URL of the item". It's pointing back to the full view of the record in Primo. That makes sense. But if available I would like to get the OpenURL here because I want to connect my users to the article or the service page and not to the Primo record again. It's fulfillment at this point!

Why the same link is also in guid is a mystery to me. RSS standard says: "guid stands for globally unique identifier. It's a string that uniquely identifies the item. When present, an aggregator may choose to use this string to determine if an item is new." What about the PNX ID?

Last not least the description:
<description>Plasmodium Falciparum -- Analysis ; Proteases -- Analysis ; Proteins -- Analysis ; Phosphates -- Analysis ; Malaria -- Analysis;</description>
Often it incorporates only "N/A" or sometimes subject headings. But the description should include the same information as the brief view in the web interface of Primo like bibliographic information, identifier, subject headings, language, etc. This is what the user will see in his feed reader of choice or what a feed aggregation system can use to give meaningful context for the title of this item. Of course it's tricky because a Primo search delivers very different types of content with very different metadata. Books have authors; journals have not. Articles are published in a journal and pictures have a resolution and digital objects have a file format.

Today there are no customization options for the feed content. If the settings of the brief view are applied to the feed too, it would improve the item description massively and solve the description problem. This need is solved for the export to a reference management software. The RSS feed for a query is not so much different from that.

Right now, only 25 records can be displayed under the “view online” tab in Primo. If this limit is increased, or removed entirely, libraries will have greater flexibility when creating collections. For example, we have 48 local portfolios that we linked to a single bib record, and we would like all of those portfolios to be displayed under the “view online” tab of that item. So, we propose removing the limit altogether, allowing libraries to decide how many records they want to appear under the “view online” tab. We worked on this project with Ex Libris, and they ultimately advised us to submit our suggestion to the idea exchange as this is considered an “enhancement request.” Thanks!

We rely on PCI alternative coverage for maintaining the best discovery layer as this enables full text access to results obtained from known-item searches and topic searches. Using both PCI alternative coverage and the Newspaper Search together present challenges. Using both of these options together result in too many false positives; false positives disappoint users and erode their trust in our discovery system.

Please consider including the Newspaper Search with the regular Primo Central updates that are compared against our institutional electronic holdings file so the Availability statements are correct. As we look ahead to the introduction of CDI, please consider including the Newspaper Search with the regular CDI updates in comparison against our institutional electronic holdings file as well.

As default behavior, Primo not only looks for the patron's query, but enriches the original keywords of the user with additional terms, in order to improve the performance.

The system first tries to guess the language of the query, and then tries to enrich it, using a variety of steps described in the Linguistic Features section of the documentation: https://knowledge.exlibrisgroup.com/Primo/ProductDocumentation/TechnicalGuide/120Linguistic_Features

For example, a query for the string: Birne
if recognised as German, is enriched with following synonyms (dictionary file as to March 2017):

gluehbirne(normal),gluehlampe(normal),lampe(normal),leuchte(normal),leuchtkoerper(normal),haupt(normal),kopf(normal),ruebe(normal),schaedel(normal)

The point is that the whole thing is a blackbox for both the librarian and the patrons. There is no way to know how the orignal query was processed, which terms were added and what was actually searched.

It would be a good enhancement to provide a) to the user i the Front End brief additional information about the terms actually searched, to make the process transparent and understandable b) to the systems librarians extended information about about the terms actually searched, to allow a better understanding of the process and a chance to set up properly the related Search Engine Configurations, the user synonyms etc.