marc translator vs. coins

I'm interested in moving my library catalog from use of a specialized translator that uses the marc import features in zotero to use of generic coins data. I can generate coins on my pages. Will Zotero be able to understand and take advantage of the coins data by default? Will the original translator for my site have to be removed from the database before Zotero will import using coins?

The current translator is NCSU Library (Endeca 2). It no longer functions because we have changed the way we make marc records accessible within our catalog.

Anyone know any disadvantages when it comes to replacing marc with coins?
  • Yes, Zotero will understand COinS by default.
  • COinS is not as robust as the MARC records. As I understand it the best of both worlds would be to serve up your MARC records via UnAPI, which would give you the stability of COinS with the data robustness of MARC. If your unfamiliar with UnAPI check out http://unapi.info/
  • Thanks...

    If I am serving up COinS, then Zotero is not going to be making use of UnAPI will it? Does Zotero automatically understand how to import a marc21 or marcxml record supplied via UnAPI?

    Realistically, I need a short term solution first, and embedding COinS is far easier than creating an UnAPI server capable of responding to various requests, which is what it sounds like I need to do based on http://unapi.info/. However, it's an interesting longer term solution.
  • edited September 30, 2008
    You can use both COinS and UnAPI on a page, in which case Zotero scrapes UnAPI. Zotero can import MARC21 over UnAPI.
  • I'm trying to offer some assistance to a librarian who wants to make an extensive Biblical Studies library available to Zotero, and would in particular to export series numbers as part of the bibliographic records, since they are commonly used for book citation in the related academic disciplines. I don't think the library uses or has MARC records? Any advice on making metadata Zotero readable? COinS seems easy, but doesn't have series number field.

    Is it practical to try to create MARC21 records on the fly and include them over UnAPI as suggested above, or is there a simpler third way that Zotero would already support?
  • MODS XML is a straight forward and rich format & is probably more widely supported over UnAPI.
  • And do you happen to know it would require (in general terms) to use MODS XML to expose the bibliographic metadata served up by an existing OPAC? Is it just a matter of embedding tags in the HTML output, like COinS, or is server infrastructure required?
    In this case the OPAC was coded in-house. Thanks.
  • You could use MODS with UnAPI. There is no way to embed it a'la COinS. Depending upon the license and the language of the OPAC, I might be able to point you to starting code.
  • I've made COinS available on my pages for Zotero integration, which works like a charm in development. However, in production, Zotero is detecting the old custom site translator based on URL and trying to use that instead (and failing). Is there any way to turn off the old site translator so that Zotero will use COinS instead?

    It's the NCSU Library (Endeca 2) translator. My site is at http://www2.lib.ncsu.edu/catalog/ .
  • COinS should always take precedence over a specific site translator, as it has a higher priority. Zotero uses COinS when I try that site in 1.0.7, and it imports fine.

    Have you altered any priority values in the database?
  • Here's what I see when running Firefox debug. It looks like it is going to the site translator BEFORE COinS. I didn't think I had changed anything in the database; is there a way to refresh? I did 'Check Database Integrity' and 'Reset Translators and Styles' under Advanced preferences in Zotero. I'm using 1.0.7, too.

    zotero(3): Translate: binding sandbox to http://www2.lib.ncsu.edu/catalog/?N=0&Nty=1&Ntk=Keyword&view=full&Ntt=baseball

    zotero(3): Translate: searching for translators for http://www2.lib.ncsu.edu/catalog/?N=0&Nty=1&Ntk=Keyword&view=full&Ntt=baseball

    zotero(5): SELECT detectCode FROM translators WHERE translatorID = ?

    zotero(5): Binding parameter 1 of type string: "da440efe-646c-4a18-9958-abe1f7d55cde"

    zotero(3): Translate: executed detectCode for NCSU Library (Endeca 2)

    zotero(3): Translate: found translator NCSU Library (Endeca 2)

    zotero(5): SELECT detectCode FROM translators WHERE translatorID = ?

    zotero(5): Binding parameter 1 of type string: "e7e01cac-1e37-4da6-b078-a0e8343b0e98"

    zotero(3): Translate: executed detectCode for unAPI

    zotero(3): Translate: executed detectCode for COinS

    zotero(3): Translate: found translator COinS

    zotero(5): SELECT detectCode FROM translators WHERE translatorID = ?

    zotero(5): Binding parameter 1 of type string: "951c027d-74ac-47d4-a107-9c3069ab7b48"

    zotero(3): Translate: executed detectCode for Embedded RDF

    zotero(3): Translate: running handler 0 for translators

    zotero(5): SELECT * FROM translators WHERE translatorID = ? AND translatorType IN (4,5,6,7,12,13,14,15)

    zotero(5): Binding parameter 1 of type string: "da440efe-646c-4a18-9958-abe1f7d55cde"

    zotero(3): Translate: parsing code for NCSU Library (Endeca 2)

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(2): cleanString() is deprecated; use trimInternal() instead

    zotero(3): Translate: running handler 0 for select

    zotero(3): HTTP GET http://www2.lib.ncsu.edu/catalog/record/NCSU2177784

    zotero(4): Translation using NCSU Library (Endeca 2) failed:
    message => tempidMatch is null
    fileName => chrome://zotero/content/xpcom/translate.js
    lineNumber => 523

    <bunch of HTML here...>

    name => TypeError
    url => http://www2.lib.ncsu.edu/catalog/?N=0&Nty=1&Ntk=Keyword&view=full&Ntt=baseball
    extensions.zotero.cacheTranslatorData => true
    extensions.zotero.downloadAssociatedFiles => false
  • Sorry, I had it backwards—the lower the number, the higher the priority. So the custom translator would in fact take precedence over COinS. (I only checked the front page of the catalog, which doesn't match the regex and therefore used COinS.)

    So you're saying you'd like us to remove the NCSU library translator for everybody. This was a custom translator we wrote for NCSU—before we remove it, do you happen to know if there are any other schools that use the same Endeca implementation as NCSU?
  • As you can probably see in the translator list, you have at least one other translator written for an Endeca implementation (FCLA). The Endeca software is not like a library catalog in that it does not come with an out-of-the-box interface. Therefore, every Endeca implementation will have a completely custom user interface designed and written by the individual library, and it seems very unlikely the translator code will be re-usable between them. I doubt you'll be able to develop a general Endeca translator.

    I can see from the Trac ticket that you have noticed the translators breaking regularly; that's why I want to move us to a COinS approach (and hopefully unAPI with MODS in the future). That way re-designs of the user interface code won't break Zotero translation.
  • The NCSU translator was removed. It should be deleted from clients within 24 hours.
Sign In or Register to comment.