Translator Primo 2018 not functioning properly

  • adamsmith
    It works for the English version of the catalog -- the problem is that Zotero looks for the display/type in the metadata and that appears to be getting localized (which we haven't seen in other non-English Primo instances).

    We can look at a fix, but it's not trivial. If you're at the library at NTU, fixing (changing?) this in the PNX would be more elegant imo. I don't think the metadata should change depending on the interface language.
  • Rainshoots
    Thanks! I'll talk to the librarian and see how it goes.
  • buhc
    We have the same problem in our new library catalogue:
    https://zhaw.swisscovery.slsp.ch/discovery/search?vid=41SLSP_ZAW:ZHAW

    The Zotero connector isn't working properly: some references are imported as document, even though the connector icon shows the correct item type.

    Example:
    https://zhaw.swisscovery.slsp.ch/permalink/41SLSP_ZAW/1ivdr18/alma990046265770205510

    We have this problem only in the german version of the catalogue, in the english version the connector is working fine.

    Is there a solution that the connector is working in the german version as well?

  • gduffner
    @adamsmith this is probably not fixable by the library itself. AFAICT these libraries use PrimoVE, an SAAS variant of Primo where the libraries have little influence on the creation of PNX data. Only ExLibris could.

    I haven’t looked at the translator code but the connector is probably looking at display/type. Could it, perhaps, if that doesn’t map to anything, look at the addata section? addata/ristype looks like a good candidate to me (at least I try to populate it accordingly in our Primo, where it’s still possible :-))
  • zuphilip
    @gduffner There is already some code which looks at the addata/ristype https://github.com/zotero/translators/blob/master/Primo Normalized XML.js#L114-L122 and this could been easily extended to the BOOK case.

    However, I am a little skeptical that the examples of primo instances above are correctly configured. It seems strange for me that the PNX data is changing depending on the chosen language of the user. The data itself should not change but possibly the label shown in some UI. At least in our own primo instance we have in the PNX data always the English "book" and only change the label to "Buch" resp. "book" in the frontend.
  • gduffner
    @zuphilip you might be right. Looking at the SLSP Primo, the Italian setting is like the German with 'libro' as value for display/title, while the French, like the English setting reads 'book'.
  • zuphilip
    What I am saying is that in the PNX data of our Primo catalog is constantly having display/type = book also when reached from another language version. This does make much more sense that the *data* is language-agnostic and only in some final step for the *UI* the label might be mapped to another language version.
  • gduffner
    Agreed, this is what I’d expect, too — and what actually does work, too, as proven by the French version of the SLSP/ZHAW Primo. But given the nature of Primo VE and the SLSP setup being a brand new one, I still suspect the service provider to be responsible for this configuration.
  • buhc
    thanks for your answers. This helps a lot. We will get in contact with SLSP!
  • nchachereau
    @zuphilip I've also been looking at this problem, and I was wondering why the translator uses this PNX data. It causes other problems with the library catalogues I use (apart from the brand new SLSP, there is Renouvaud https://renouvaud.hosted.exlibrisgroup.com/):

    - Title parts are not separated by a dot or a colon, so you have to fix them yourself in the data (for instance here https://swisscovery.slsp.ch/permalink/41SLSP_NETWORK/1ufb5t2/alma991089654239705501). This problem is also common on Renouvaud (even though, checking right now, it seems to have been fixed).
    - Because location and publisher are included in the same field, the translator has some clever tricks to take care of that, but in one case today, because the field said "Cambridge Cambridge University Press", I ended up with "University Press" (https://swisscovery.slsp.ch/permalink/41SLSP_NETWORK/19n6r1g/alma991035716229705501).
    - In Renouvaud, the publisher name often ended up mangled, e.g. "AMichel" instead of "A. Michel" or "Albin Michel". I cannot find a new example of this right now, so it might have been fixed.

    Such problems do not appear in the RIS or BibTeX data that can be exported from the interface. But it also seems less complete. Still, I was wondering about the trade-offs and the thinking that went into the translator.

    Also wondering about the fact that the Renouvaud metadata seems to have been fixed (or maybe I'm just lucky tonight): does that maybe mean there is a new version of Primo, so that with a bit of patience things will get fixed in SLSP's Swisscovery as well? Or did this improvement involve metadata cleanup?
  • zuphilip
    PNX data should be very rich data and cover (almost) all data from primo instances. This is not the case if we would only take RIS or BibTeX data instead. Moreover, PNX data should be normalized (that is the "N" in PNX) and therefore (at least in theory) work well and consistent among a lot of Primo catalogs in various countries.

    I and @adamsmith had some contact with ExLibris and worked with them together for example to make sure that the new interface in 2018 or also Primo VE is supported by the Zotero translator.

    However, I see that in some of the examples here the extracted metadata in Zotero are not yet that good. But the reason seems for me to lie in the PNX data itself, e.g. see


    {
    "display" : {
    "source" : [ "Alma" ],
    "type" : [ "Buch" ],
    "title" : [ "The chimney of the world a history of smoke pollution in Victorian and Edwardian Manchester" ],
    ...
    "publisher" : [ "Cambridge The White Horse Press" ],
    ...


    Why is the type translated in the *data*? Why is there no separation for the subtitle? Why is the place also part of the publisher field and then also without any colon ":" or similar separation sign? I don't believe that these data are correct as they are at the moment. If this is true, then someone needs to fix them. Only for things which cannot been fixed or for which there are naturally some variations in the data, it makes IMO sense to adjust the Zotero translator.
Sign In or Register to comment.