Tag Archives: link resolvers

“Primo is broken, can you fix it?” #anzreg2019

“Primo is broken, can you fix it?”: Converting anecdotal evidence into electronic resource access in Alma and Primo
Petrina Collingwood, Central Queensland University

Combined library and IT service. EZproxy/ADFS authentication.

Problem: implemented quickly in late 2016; in 2017 received lots of reports of broken links (derived from unforeseen consequences of config choices – including moving EBSCOhost auth from EZproxy to SSO). Limited staff resources to troubleshoot. New Digital Access Specialist position created to fix issue.

Approach: sought examples of issues, devised a plan to systematically check P2E records, check parsers, check static URLs correct, etc

Cause of errors: multifarious! Incorrect metadata in PCI or target databases or Alma, configuration of parsers or electronic service linking or EZproxy config, limitations of EBSCO link resolver, incorrect availability/coverage, links not proxied in Primo.

Major problems: EBSCOhost links; EZproxy not enabled on some collections; EZproxy config stanzas not maintained; standalone portfolio static URLs not maintained.

Fixed: 15,000 Kanopy standalone portfolios not proxied so moved into a collection for easy solve. Reduced EZproxy stanzas by 63%. All Ebscohost collections had major issues.

Late 2017 moved EBSCOhost from EZproxy to SSO for convenience of students, but

  • Alma’s generated link didn’t work as it didn’t use the authtype or custid parameters. The authtype parser parameter wasn’t configurable – opened a case and Alma fixed this.
  • EBSCO link resolver plugin gives more accurate links but again missing authtype and custid parameters so didn’t work off campus. Integration profile in Alma contains the API user ID but no username/password to access CQU account so Ex Libris just pulled back generic URLs which wouldn’t work. Ex Libris wouldn’t fix this.
  • EBSCO link resolver – when plugin not enabled, OpenURL is used, but gives errors any time volume or issue numbers not available. EBSCO had no plans to fix this. Workaround was to create a dynamic URL in the Electronic Service. Gigantic code with four IF statements covers most situations….  Problems with URLENCODE function so lots of issues whenever diacritics, copyright symbols etc. Ex Libris has this in development. Also has no access to jkey parameter which is a problem for regional newspapers where the Alma title doesn’t match the EBSCO title.

Essentially the solutions to the problems caused more problems….

Remaining possible solutions:

  • Go back to EZproxy (unfortunately lots of links in Moodle)
  • Go OpenAthens (probably worse than going back to EZproxy)
  • Unsubscribe to EBSCO (tempting but not practical)
  • Do nothing (use current FAQ workaround)
  • After URLENCODE bug fixed, turn off EBSCO link resolver plugin in Alma and implement Dynamic URLs
  • When URLENCODE bug fixed, ask Alma to use Dynamic URLs for everything

“No full text error” problem – caused because a PNX record might have 3 ISBNs and Alma 2 ISBNs, one matches so we get “full text available” – but then OpenURL only sends one ISBN and if it’s not in Alma it returns “No full text error”. Ex Libris says this is pending development.

Most issues demystified and many even solved. Still working to resolve some.

Q: Would it get anywhere if a bunch of libraries get together to lobby EBSCO to fix their link resolver?
A: Maybe; not sure of their reasons for hesitating.

“It should just work”: access to library resources #anzreg2019

“It should just work”: access to library resources in Discovery layers and Open Web searching
Kendall Bartsch, ThirdIron (Gold Sponsor)

Link resolvers cumbersome, often claim “full-text available” but… it’s not…. Or there are too many options so confuse users who just want the text. Perception from users that the button “almost never works”. Suggestion to “just do what SciHub does”. Various other solutions like ResearchGate, Academia.edu, Reddit, #ICanHazPDF – sharing and piracy “steal” an estimated 20% of usage from publisher sites. [Some of this because link resolver clunky, much also because people aren’t members of libraries that can afford what they want.]

ThirdIron reinvented a linking syntax LibKey. Based on:

  1. article metadata – essentially a dark archive of Crossref, but also metadata from other sources too. Vet, correct, normalise, maintain data (tells CrossRef about mistakes they find), and incorporate open access metadata including OADOI.
  2. entitlements data – tools to import holdings data across different vendors who all represent holding data differently
  3. library authentication/fulfilment

When a user requests an item, all this is put together by LibKey and results in the PDF or abstract URL.

LibKey Discovery: This can be integrated into various discovery layers including Primo: links could be “download PDF”, “view issue contents”, “read article”, etc (recently including if in html only not PDF).

LibKey Link: Want to also expand service into anywhere else you’d use an OpenURL base url, eg Google Scholar, or linking from Web of Science, reference lists etc. Can fall back to regular link resolver. (This is coming soon.)

LibKey Nomad: Linking from web searching – browser extension that can be downloaded by individual or installed on an enterprise basis.


  • increasing delivery of PDFs
  • libraries reporting fewer support tickets
  • libraries estimating savings of researcher time