October 2015


Once upon a time we wrote out longhand a list of our books in a ledger, and we chained the ledger to a lectern. And it was an OK system because we had so few books and so few people could read. There wasn’t exactly a crowd of people queued up to find a book.

Eventually we typed out all our data onto 3×5 index cards. And it was an OK system because we alphabetized and cross ref’d and made cryptic little pencil notations and filed the cards neatly in little drawers and let the public rifle through them.

Then in the 60s someone thought “Hey! Wouldn’t it be fun to be able to exchange cards with each other so that every library didn’t have to catalog every book from scratch, and when a member of the public (through carelessness or malice aforethought) damaged or lost one of our precious 3×5 cards we could snap our fingers and magically produce a new one instead of typing it all over again?” And Lo! Henriette Avram invented machine readable cataloging and the Library of Congress launched a world-scale game of Library: The Gathering. And it was an OK system because getting a package of cards in the mail was like Christmas every week!

Once we had machine readable cataloging all the librarians decided they also needed machines, and automated library systems spread like a plague of ones and zeroes across the globe. But the early automation systems were staff only. For Librarians By Librarians (also the name of my line of snazzy cardigans). The eureka moment arrived when someone (possibly in Ohio and doubtlessly bathed in a sickly VT100 glow) thought “Hey! Maybe the readers would like to look at all this data on a screen instead of card stock.” And the OPAC was born. And it was an OK system because the multitudes cried out in gratitude: “Well, it’s better than nothing!”

And it really was better than nothing. But it could have been so much better. When the web arrived a lot more options for presenting our list of books arrived with it, and the web-based OPAC was born. Or, rather, the web-based OPAC took the existing OPAC and made it point-and-clickable. It took another decade for librarians and systems vendors to attempt anything that really leveraged the new technology. And it was an OK system because at least you could browse for books from home in your pajamas (as long as you had an Internet connection that wasn’t WebTV.)

We’re making attempts now – to use new technologies, new ways of thinking about search (thanks, Google!), sussing out the ways that our users actually interact or want to interact with our data and taking into account the huge amount of stuff we own or have access to that’s not a book. We’ve had varying degrees of success. As we implement new “next-generation” and “web-scale” systems that are focused on user discovery of info resources, instead of focused on the business of running a library, some features and functions have been set aside. It remains to be seen which, if any, of those will be re-adopted as time goes by, but one feature that was missing from our OneSearch discovery system was the ability to view the original MARC record for the resource you’ve just found in the catalog. And it was missed. Primarily by library staff, not our users, but missed nonetheless, and missed enough to try to get back.

Investigative Process:
Q: Does the feature exist already in Primo? Maybe it’s just not turned on?
A: Nope. That was quick.

Q: What have other Primo customers done? Has anyone already done this and put their code somewhere and we can borrow it?
A: Yes – Jeff Peterson at University of Minnesota posted a pretty nice method to the Primo Discussion List, involving a small jsp file, and changes to the Primo normalization rules and mapping templates that will create an entry in the Links menu on the Primo Details tab.

Q: Did they do it in a way that will work in our environment?
A: Yes, absolutely this would work in our environment, though it would require a full renormalization to create the links, which is less than ideal.

Q: Is there a better way?
A: Better is debatable, but there was a quicker way for sure, involving jsp, XSL and Primo RTA. So that’s what we did. The result is a link in the Actions menu in the Details tab.

Intrigued? If you’ve read this far you must be anxious to get the inside story from Greg McClellan.
menu

Convincing Primo to show us the MARC record

The ability to view the full MARC record is a feature that existed in our previous two catalogs – Louis (Aleph OPAC) and LouFind (VuFind). It’s a feature that is missed by staff, so we explored our options and settled on a modified version of a method devised by Jeff Peterson at University of Minnesota. Jeff’s method involved using jsp, Primo normalization rules, and Primo mapping templates to create an entry in the Links menu on the Primo Details tab. Since that method would require a full renorm/reindex of Primo, we looked for a shortcut, and found one that enabled us to build the links on-the-fly instead of through norm rules.

Only two file modifications are needed to do on-the-fly retrieval of the MARC record from Alma.

  1. footer.html
  2. marc.jsp


footer.html – added a new section

  • uses jquery (a javascript library)
  • checks that it’s on a full record page (details tab)
  • gets the Alma MMS ID from either the URL or embedded in the record in a hidden field (.EXLResultRecordId) (script looks for both because one or the other will exist depending on what path you took to arrive at the details tab)
  • uses javascript to find the Actions menu and append a link called Staff View
  • if the link is clicked, marc.jsp is invoked

marc.jsp – new file

  • lives in a custom directory in fe_web (so it won’t be overwritten by service packs)
  • created by Jeff Peterson at University of Minnesota
  • only modifications needed were to insert our local hostname and institution
  • uses the Alma MMS ID (retrieved by the footer.html jquery section described above) and Primo RTA (Real Time Availability) to retrieve the full marc.xml record from Alma
  • uses embedded XSL to transform the marc.xml record into the huma-readable form of MARC we know and love

Pros

  • Fast to implement
  • No Primo renorm/reindex needed

Cons

  • The MARC record retrieved is the up-to-date version from Alma and reflects any changes to the MARC record that have been made since the last time the record was published to Primo – there is a potential lag time of several hours between record edits in Alma and their appearance in Primo. Because the Staff View is most likely to be used by staff, we felt there wasn’t a large risk for confusion.

If you’d like more details and code samples, please feel free to contact us via the “Leave a Reply” section.

 

actions menu

Protected by Akismet
Blog with WordPress