Add translator to repository

[jouchida]

Hi, we'd like to submit this translator for the USC Libraries catalog.

https://gist.github.com/1561521

Thanks,
Joyce

[Avram Lyon]

Joyce,

Since this translator is just a copy of the Rice modifications of the
SIRSI translator, it would be best to just modify the Rice translator
to support both catalogs. And if this translator can be expected to
work out-of-the-box for more sites than USC and Rice, the right action
to take at this point is to find ways to identify such SIRSI
installations and run this modified version on all of them.

Are you using a particular version or module for SIRSI that requires
these changes? We'd like to stay away from single-library
modifications when a single translator would work, since the former is
a maintenance nightmare.

Thanks for working on this-- I look forward to getting this out!

Avram

> --
> You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> To post to this group, send email to zoter...@googlegroups.com.
> To unsubscribe from this group, send email to zotero-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
>

[jouchida]

Hi Avram,

Yes, I think this translator should work for Sirsi installations that
use the eLibrary OPAC templates. The problem is that I don't think
there is a way to specifically identify eLibrary installations vs.
earlier Sirsi templates (that use translator Library Catalog
(SIRSI).js) just by the URL. If we assign a lower priority number to
the eLibrary translator and item metadata is not found, does Zotero
fall back to the next higher priority number translator that matches?
In that case, the same regex target can be used for both translators.
Or do you have other suggestions?

--Joyce

[adamsmith]

Obviously working through the target regexp for the URL is preferable
(i.e. less resource intensive), but if that's not possible yes,
starting with the eLibrary-Sirsi and falling back to regular Sirsi
should work as long as the detect function for eLibrary-Sirsi will
return false for regular Sirsi catalogs. It needs to fail at the
detect level, though, not during the actual import.
Are we reasonably sure that's the case? Does someone have a couple of
examples of old fashioned SIRSI?
Sebastian

[Avram Lyon]

On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote:
> Obviously working through the target regexp for the URL is preferable
> (i.e. less resource intensive), but if that's not possible yes,
> starting with the eLibrary-Sirsi and falling back to regular Sirsi
> should work as long as the detect function for eLibrary-Sirsi will
> return false for regular Sirsi catalogs. It needs to fail at the
> detect level, though, not during the actual import.

I'd be happy to see this as a fallback during detection. Just try to
make the eLibrary-Sirsi detectWeb return false as quickly as possible
for non-eLibrary installs.

Joyce, would you feel comfortable taking this on and doing a little
testing on eLibrary and non-eLibrary sites?

Avram

[jouchida]

Hi,

I created a new gist: https://gist.github.com/1597917

The code is essentially the same as Rice University's translator (so I
kept the creator the same), but I've genericized the regex, the
priority code, and some branded values within the javascript. I didn't
edit the detectWeb code, it seemed to already be working fine. I've
tested on Sirsi sites (as listed under Unicorn on this page:
http://www.librarytechnology.org/arl.pl) and confirmed that both pre-
eLibrary and eLibrary sites are zotero-enabled, with some exceptions
due perhaps to template customizations by the institution. eLibrary
sites that are not currently zotero-enabled become zotero-enabled when
this translator is installed locally.

Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to
take precedence over this translator, which is fine since I don't want
to mess with their connectors.

Anyway, as far as I can tell, this should work for Sirsi eLibrary
catalogs and not break other Sirsi connectors. Let me know if there
are any issues. I'm a zotero newbie so I might have missed something.

--Joyce

[Avram Lyon]

Joyce,

I want to clean up the code some before rolling this out, in part to
ease future troubleshooting and in part to make it possible to add
support for other e-Library installs that it doesn't currently
support. I would be very interested in making the translator continue
using MARC data, since our current approach of using natural language
labels in the interface will break down very quickly internationally.

Can you, your local SirsiDynix specialists, or anyone else on the list
say whether there's a way to get MARC data through the OPAC without
going to Display Options --> unformatted display --> Full Record?

Doing this through scraping alone isn't going to cut it, I'm afraid.

I can redirect my question to code4lib if need be.

Avram

[jouchida]

As far as I and my colleagues know, that is the only way to get MARC
data through the OPAC: Display Options --> unformatted display -->
All. I think All is more complete than Full.

--Joyce

On Jan 11, 9:41 pm, Avram Lyon <ajl...@gmail.com> wrote:
> Joyce,
>

[jouchida]

Hi,

I wonder if any progress has been made on this translator. We have
received many patron inquiries about Zotero-compatibility since we
upgraded to eLibrary, and we've been offering our translator as a
local download.

Re MARC data: looking at the original Zotero translator for Sirsi
(Library Catalog (SIRSI).js), there is an import function that uses
some URL to get MARC data. I will follow up with Sirsi support and try
to get more specific details about it.

Thanks for your help,
Joyce

[jouchida]

Never mind my last comment on MARC data -- it's not an import
function, and the same code exists in the updated translator.

[Avram Lyon]

Pushed general eLibrary, tested on PSU, Rice, USC. Doesn't run on
Rutgers, so I kept the separate IRIS translator for now.

Sorry for the delay and thanks for your hard work on this one!

Avram

[jouchida]

Just saw this post, thanks!!!