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.
Thank you posting this idea. Moving it to under review for further analysis.
Did not make it through round two of NERS.
Bas Vat commented
Would be very helpful voor UBL
NERS 7893, round two open for voting now.
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
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
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.