Error capturing record in Zotero 1.0.10 via unAPI, MODS, and Evergreen 1.6

dbs

Hi, we were happily using Zotero to capture records via unAPI + MODS in Evergreen, but after a recent upgrade of our Evergreen server Zotero no longer is capable of capturing records. The Zotero icons light up, but when we try to capture a record the "Could Not Save Item" dialogue displays.

The unAPI validator reports the same problems on our Evergreen server as with previous versions of Evergreen, and manually checking the URLs and resulting MODS record it seems that everything is working.

Some example URLS for:
* Search result that triggers the Zotero icon: http://laurentian.concat.ca/opac/extras/opensearch/1.1/CONIFER/html-full?searchTerms=apache+derby&searchClass=keyword
* unAPI formats list: http://laurentian.concat.ca/opac/extras/unapi?id=tag:laurentian.concat.ca,2009:biblio-record_entry/739015
* MODS record served up via unAPI: http://laurentian.concat.ca/opac/extras/unapi?id=tag:laurentian.concat.ca,2009:biblio-record_entry/739015&format=mods

In comparison, Evergreen 1.4 at http://dev.gapines.org/opac/extras/opensearch/1.1/PINES/html-full?searchTerms=trip&searchClass=keyword works great.

Any thoughts?

dstillman

The namespace on your MODS record is invalid. It should be "http://www.loc.gov/mods/v3", not "http://www.loc.gov/mods/".

I believe Zotero's MODS translator wasn't properly checking the namespace until a recent update.

dbs

Ah! Arguably, the namespace is correct for what's being served up, because our "mods" format points to a MODS v2 record; our "mods3" format points to a MODS v3 record (per the "namespace_uri" attribute in the unAPI formats list).

So I suppose I should change the name of the MODS v2 format from "mods" to "modsv2" and change "mods3" to "mods". Thanks for the help!

dbs

And, just for followup, I've finally committed a fix for the problem at http://svn.open-ils.org/trac/ILS/changeset/14181 so this will be fixed in the Evergreen 1.6 release. Thanks again for the help.