Princeton Primo Translator

ausj02 · December 13, 2013

Hello,

I'm trying to save to Zotero from Princeton's Primo installation and running into constant errors. I always get the message:

"An error occurred while saving this item. Check Known Translator Issues for more information."

The URL to a sample record is here. http://searchit.princeton.edu/primo_library/libweb/action/dlDisplay.do?docId=PRN_VOYAGER2778598&vid=PRINCETON&institution=PRN&showPNX=true

Do you think this would be an easy fix? I am just now reading up about primo integration in general but don't believe we have ShowPNX enabled. Suggestions how to get this working?

adamsmith · December 13, 2013

if you're using Zotero for Firefox, this will probably work if you right-click on the URL bar icon and select "Save to Zotero using Primo"

If that's the case, it'd be great if you could report this to Princeton library - they wanted to have their own translator included in Zotero, so they're in charge of maintaining it - we'll be happy to answer any questions, but I don't think that should be that hard for them to fix.

ausj02 · December 13, 2013

Will do, thanks!

ausj02 · December 13, 2013

After a little more digging, I see a seemingly simple JS error that may be at the root of my problem:

[JavaScript Error: "superCleanString: argument must be a string"]

Since no line is mentioned with the error, it's hard to know where to look. Has anyone encountered this problem before? Are there a few 'hotspots' in a translator file that this problem would be expected?

Submitted a debug report if it helps:556499599

adamsmith · December 13, 2013

There error occurs here:
https://github.com/zotero/translators/blob/master/Princeton%20Catalog.js#L136
but the underlying problem is that the translator simply doesn't find a title in the PNX (i.e. Primo's XML) data, which is presumably the case because the PNX format changed - as I say, the regular Primo translator does fine on that page.

adamsmith · December 14, 2013

I've heard back from Princeton Lib, they're working on a fix.

ausj02 · December 14, 2013

Great, thanks a lot for the help.

kevin.reiss · December 14, 2013

The issue relates to the use of Primo's "deep" linking syntax in the URL:

http://searchit.princeton.edu/primo_library/libweb/action/dlDisplay.do?docId=PRN_VOYAGER2778598&vid=PRINCETON&institution=PRN&showPNX=true

showPNX=true does not work when this syntax is used. For Primo libraries who use deep links and want to support Zotero a different path to PNX must be provided. In the standard translator some has been put in to handle this:

https://github.com/zotero/translators/blob/master/Primo.js#L96

We will either submit a patch that includes this pass through for the Princeton translator or request that our current custom translator be retired in favor of the standard one which seems much expanded than when we first put in our custom one.

Regards,

Kevin Reiss
Princeton University Library

adamsmith · December 14, 2013

Kevin - should I just go ahead and lower the priority of the Princeton+ translator as a stop-gap until you've decided which way you want to go with this? That way it wouldn't get used, but would still be available and quick to revive.

kevin.reiss · December 14, 2013

That is a good idea Adam. I should be back in touch with you on this early next week.

adamsmith · December 15, 2013

Kevin - done. But that doesn't actually solve the deep link problem. It does solve a separate problem that also prevented regular items (i.e. search results) from importing from your catalog, so I still went ahead, but the resolution of the deep linked syntax URLs actually only works with the showPNX.js script installed on your server - which either isn't the case or isn't working correctly.
More info here:
https://forums.zotero.org/discussion/31294/possible-solution-for-primo-bug/

kevin.reiss · December 16, 2013

Hi Adam,

We have a working showPNX.jsp script on our server:

http://searchit.princeton.edu/primo_library/libweb/showPNX.jsp?=PRN_VOYAGER7343340

However when using Primo.js with the followign URL:

http://searchit.princeton.edu/primo_library/libweb/action/dlDisplay.do?docId=PRN_VOYAGER7343340
&vid=PRINCETON&institution=PRN

I get this error logged to the Zotero console:

(3)(+0000001): HTTP GET http://searchit.princeton.edu/primo_library/libweb/showPNX.jsp?id=0

(3)(+0002048): Translate: Function 0 did not work.

(3)(+0000001): HTTP GET http://searchit.princeton.edu/primo_library/libweb/action/dlDisplay.do?institution=PRN&vid=PRINCETON&docId=PRN_VOYAGER7343340&showPnx=true

(3)(+0000279): Translate: Function 1 did not work.

(3)(+0000000): Translate: Could not determine PNX url from http://searchit.princeton.edu/primo_library/libweb/action/dlDisplay.do?institution=PRN&vid=PRINCETON&docId=PRN_VOYAGER7343340

(3)(+0000000): Translate: Translation successful

(5)(+0000000): Translate: Running handler 0 for done

It appears that the translator is having trouble fetching the PNX ID from the dlDisplay.do page.

adamsmith · December 16, 2013

thanks. The other Primo catalogs do display PNX for the equivalent
http://searchit.princeton.edu/primo_library/libweb/showPNX.jsp?id=0
(see e.g. the Mannheim catalog linked or the Oxford catalog in the test)
working off the active session.

It would seem like a more robust solution to work with the actual docIds, but I probably won't have the time to look at that very soon. Obviously we'd accept a patch as long as it doesn't break anything else

kevin.reiss · December 16, 2013

I guess what I'm missing here is how does

http://solo.bodleian.ox.ac.uk/primo_library/libweb/showPNX.jsp?id=0

actually go out and fetch the PNX data for the test URL in the translator.

http://solo.bodleian.ox.ac.uk/primo_library/libweb/action/dlDisplay.do?docId=oxfaleph010311597&vid=OXVU1

adamsmith · December 16, 2013

it just fetches the first (in this case the only) result of the last opened display.

It's not the most robust solution - if you have Primo open in two tabs it creates chaos, e.g. - so something more robust would be good.

aurimas · December 16, 2013

This will be a bit tricky. E.g. http://solo.bodleian.ox.ac.uk/primo_library/libweb/showPNX.jsp?id=oxfaleph010311597 does not work for http://solo.bodleian.ox.ac.uk/primo_library/libweb/action/dlDisplay.do?docId=oxfaleph010311597&vid=OXVU1 but http://solo.bodleian.ox.ac.uk/primo_library/libweb/showPNX.jsp?id=0 does.

aurimas · December 16, 2013

@kevin.reiss I'd have this working for Princeton, but the PNX returned from http://searchit.princeton.edu/primo_library/libweb/showPNX.jsp?id=PRN_VOYAGER7343340 does not have an <?xml version="1.0" encoding="UTF-8"?> header (of course with an appropriate encoding, since it doesn't seem to be UTF-8)

Also, the translator is working fine for me with the "showPnx=true" method. Though the URL it fetches is different from what you see: http://searchit.princeton.edu/primo_library/libweb/action/display.do?dscnt=1&elementId=1&vl(1UI0)=contains&recIdxs=1&frbrVersion=&scp.scps=scope:(OTHERS),scope:(FIRE),scope:(RECAP),scope:(EAD)&tab=location&dstmp=1387230551869&srt=rank&mode=Basic&vl(157986346UI0)=any&indx=2&tb=t&renderMode=poppedOut&vl(freeText0)=war&vid=PRINCETON&fn=search&frbg=&displayMode=full&ct=display&dum=true&recIds=PRN_VOYAGER6129606&doc=PRN_VOYAGER6129606&tabs=detailsTab&fromLogin=true&showPnx=true

adamsmith · December 16, 2013

yes, it works for regular usage of the catalogs, which is why I pushed the lower priority for the Princeton+ translator, which was entirely broken, but it won't work for the Permalink.
Not sure how important that is, but it would obviously be nice if it worked.

aurimas · December 16, 2013

Ah, yes, missed the permalink part. That should work with a patch I have if the xml header and encoding were sorted out.

zuphilip · February 13, 2014

I have some experience with "scraping" things from primo: Primo seems to work with sessions, cookies and some ugly redirecting mechanisms. Normally, a human perform a search in primo and thereby create the session, cookies and maybe some redirections. This things will not created if you use a "permalink" with dlDisplay.do. Moreover, if you wait too long your session will expire. Since the JSP file will use a function which looks for the current running session, it will not work in these cases. @aurimas: Did your patch solve the problem?

adamsmith · February 13, 2014

yes, Aurimas solved this simply by adding another attempt to get the PNX. Princeton's handling of this is actually objectively better, since it calls the JSP script with a stable article ID, so it will still work when you have multiple tabs/windows open, which isn't the case for the Mannheim/Oxford catalogs.

kevin.reiss · February 13, 2014

Hi,

Our "getPnx" pass through should return XML in proper character encoding and with the XML declaration and now seems to work quite well with the standard translator in the repository for Primo. Sorry for the delay in responding. The one problem with the getPnx approach is one needs filesystem access to your Primo environment to put it in place.

zuphilip · February 13, 2014

That sounds interesting. Do you have PrimoCentral or any Third Node Adapter connected to Primo? That is normally the point where one need to use the information from the session.

paulthelibrarian · September 23, 2014

We've been using the Princeton translator successfully at Harvard, but in some cases, the page numbers are not included in article citations. I am not sure if there was a recent change to Primo PNX records, but the translator is looking for //addata/pages - the problematic record has spage and epage:
<addata>
<aulast>Nath</aulast>
<aufirst>Anjali.</aufirst>
<au>Nath, Anjali</au>
<atitle>
Seeing Guantánamo, Blown Up: Banksy’s Installation in Disneyland
</atitle>
<jtitle>American Quarterly</jtitle>
<date>2013</date>
<risdate>2013</risdate>
<volume>65</volume>
<issue>1</issue>
<spage>185</spage>
<epage>192</epage>
<issn>0003-0678</issn>
<eissn>1080-6490</eissn>
<genre>article</genre>
<ristype>JOUR</ristype>
<url>
http://muse.jhu.edu/journals/american_quarterly/v065/65.1.nath.html
</url>
</addata>

Thanks,
Paul

adamsmith · September 23, 2014

we should be able to add that. I'll let you know when we have it fixed.

zuphilip · September 23, 2014

@adamsmith: I will improve it now.

adamsmith · September 23, 2014

zuphilip's patch is now life and will work automatically or after clicking "Update Now" in the general tab of the Zotero preferences. I know from Amanda and Keely that you might have more issues with the new Harvard+, here is as good a place as any to bring them up.