Skip to content

How can we improve Primo?

← Primo

Primo VE: Ability to use norm rules to specify which 856 (Marc) fields display in Links service

In Primo Back Office (BO), it is possible to use normalization rules to specify which 856 Marc fields display in the "Links" section of the Primo full record view. (See attached screenshot.)

We would like the same functionality in Primo VE to choose which 856 links to display based on the 856 first and second indicators and/or the subfields of the 856 field. Thank you.

294 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Marcus Jun shared this idea  ·   ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Nicholas Pavlovic commented  · 

    This would also help Summon over Alma customers as this piece of the Alma Services Page is based off Primo VE architecture. Case 06602563

    "It turns out that it is not currently possible to configure the 856$u links through Alma's Discovery configuration. This is true for both Primo VE and Summon over Alma. The links will always display by default, and it is not possible to add a proxy prefix or to configure them not to display."

  • Manu Schwendener commented  · 

    Hi Nili, can I ask where we stand with this?

    'Under review' since March 2021.

    (We'd like to use the normalization rule on 856 for something else than just suppressing the field, this is how I landed here.)

    > In Primo Back Office it is possible ...

    A parity issue, then.

  • Bas Vat commented  · 

    Would be very helpful voor UBL

  • Crystal Clements commented  · 

    This is needed. How will users know which link to use in shared consortial records? They will be so frustrated with clicking through useless links, and we can't just not link to resources at all as a solution to that problem.

  • Adam Schiff commented  · 

    This is an important functionality that should have been included in VE from the very beginning. It's mindboggling why it would be removed in the new version.

  • Erin Grant commented  · 

    There are so many different kinds of links - some useful/some not, some institution-specific/some not, etc. - in 856 in both P and E records. A greater ability for customers to customize their display at the IZ level using indicators (especially 2nd), regexp, or (preferably) a mix of both is absolutely CRUCIAL for user experience. We can't just throw 4-8 links of varying usefulness and applicability to users for every resource. There are some links (e.g. to archival finding aids on P records) that we need to display to users, but we don't want them lost in a sea of other links. An all-or-nothing link display approach is just not robust enough for most institutions in this regard. Please, please, please develop a way for institutions to more selectively display these links.

  • Diana Brooking commented  · 

    Since we are pulling shared records from a bib utility on a daily basis into our Network Zone, there are all kinds of 856 fields added to the bibs, even locally proxied urls that people aren't supposed to put in the shared records. It is pretty essential to be able to control display of bib 856s in order to provide the least frustrating experience to the user possible. And controlling display is way more labor effecient that grooming each bib record.

  • Mark E. Braden commented  · 

    It's baffling to see "_4" interpreted as a URL intended for public display, if the 856 is merely present in a bibliographic record.

    If this is an intended behavior in VE, it seems to assume that one would craft a MARC record so it contains only data intended for public display (in one or another section).

    I'm accustomed to using the Discovery tool (which I see in VE and Primo for other fields) requiring specific coding, to make it part of the public display.

    Because 856 links may point to resources that require license, or other 'walls', what use case of common behavior in libraries would compel me to accept any 856 in public display?

    Many thanks for your efforts.

  • Israel Yanez commented  · 

    Our consortium is currently participating in Go VE. Many campuses in our consortium use local extension 956 as a direct equivalent to MARC 856. Is there any chance the local field 956 could be added to this review for inclusion in the Links section?

  • Marcus Jun commented  · 

    Here's an example

    Primo permalink
    https://wrlc-gwu.primo.exlibrisgroup.com/permalink/01WRLC_GWA/1j51gk4/alma9913039413104101

    MARC Bibliographic Record
    856 40 |u http://public.eblib.com/choice/PublicFullRecord.aspx?p=6402759

    856 40 |3 EBSCOhost |u http://search.ebscohost.com/login.aspx?direct=true&scope=site&db=nlebk&db=nlabk&AN=2682898

    856 40 |3 OverDrive |u https://www.overdrive.com/search?q=F8EC0098-E7E7-4D4A-9742-4F355E97D342

    856 4_ |3 Excerpt |u https://samples.overdrive.com/?crid=f8ec0098-e7e7-4d4a-9742-4f355e97d342&.epub-sample.overdrive.com

    856 4_ |3 Image |u https://img1.od-cdn.com/ImageType-100/0116-1/{F8EC0098-E7E7-4D4A-9742-4F355E97D342}Img100.jpg

  • BY Z commented  · 

    You can use 1st indicator; 4 if you want the link to display, any other value if you don't want the link to display.

Primo: Primo VE

Categories

Feedback and Knowledge Base

(thinking…)