COinS for Zotero cause problems with LibX

corinna_harvard
Hello - we recently implemented a new version of our online library catalog, using the AquaBrowser software. Our old OPAC, based on Aleph, exists in parallel.

We would like to embed COinS in the new catalog, but when we do so, our LibX add-on sees the COinS and inserts a button into the page directing users back to our old catalog. Has anyone else encountered a similar problem? Here is an example from a small test database under construction:
http://dag.discovery.lib.harvard.edu/?itemid=|library%2fm%2faleph|009610179

If we cannot use COinS, is there a way we can support Zotero by using the RIS export option in our catalog?

Thank you,
Corinna

Harvard University Library
  • noksagt
    This is not a Zotero question. COinS is an open standard that does not have a specific resolver.
    our LibX add-on sees the COinS and inserts a button into the page directing users back to our old catalog.
    You choose the OpenURL resolver that will be used when you configure your LibX for your institution. You should update your OpenURL resolver to point to your new catalog.
  • mcburton
    Corinna,
    If you has an RIS available than we can write a zotero library for your AquaBrowser installation. Are you able make the RIS files available via a URL parameter (like &format=RIS) or via a URL with the item ID? If I can easily reach the RIS file from the web than we can make your site Zotero compatible.

    Matt Burton
  • noksagt
    The demo page has a link to RIS ("Export record to Endnote") that is available via a URL parameter. It also has a human-readable MARC format. Might be worth seeing if/where AquaBrowser makes raw MARC data available.
  • jkglenn
    This is a LibX issue IMO, and one that has frustrated me to no end. See this recent thread on the LibX mailing list:

    http://www.mozdev.org/pipermail/libx/2009-June/000506.html

    For many, COinS is the preferred way of exposing library catalog data to Zotero: It's standards-based and easy to implement. But there is a conflict between how LibX makes use of COinS and how Zotero does. In LibX, COinS are used to point patrons to your OpenURL resolver, which in the context of the catalog just means you're sending them around in circles.

    The solution is to give LibX maintainers more fine-grained control over where COinS cues (and preferably all cues) are displayed – functionality that's existed for years in Greasemonkey and has been promised in LibX 2.0. In the meantime you can contact the LibX developers and ask them to put your catalog on the global block list for COinS, which will ensure that the cues do not show up. Unfortunately this applies to all LibX editions, so if there are LibX users from other institution who are searching your catalog they will not see a cue linking back to their local resolver.

    That said, COinS do not always provide the most useful bibliographic data (especially if they are autogenerated), so it's worth taking a look at other ways of getting data into Zotero, like unAPI.
Sign In or Register to comment.