Library Catalog (Voyager 7) translator gets wrong call number

marnenlk
I'm reporting a problem with the Library Catalog (Voyager 7) translator; the debug ID is D1332714725.

Steps to reproduce are as follows:

1. Visit http://endeavor.flo.org/vwebv/holdingsInfo?bibId=591331
2. Import record to Zotero (I'm using the Chrome connector to do so).
3. Look at the new Zotero record.

Expected result:

The Call Number field in Zotero should be ML410.T28 N3 1969 as on the Web page.

Actual result:

The Call Number field is ML410.C4 N3 1969.

I'm using Zotero 4.0.17 and Chrome 38 on Mac OS X 10.8.
  • marnenlk
    I should mention that the problem persists with Zotero 4.0.23. I clicked Update Translators too, but that didn't help.
  • adamsmith
    Zotero grabs the call number from the MARC record (click on "Staff View" on the right.) You'll have to take this up with your library.
  • marnenlk
    Right, I thought I saw that it was doing that, but is that desired behavior, and if so, why? That is, why does it bother with MARC rather than using the actual library call number?
  • adamsmith
    because the MARC is the standardized display of information for Voyager Catalogs. How the actual page looks--and where the call number is--is going to be different for every V7 instance.
  • marnenlk
    The markup contains fieldLabelSpan and subfieldData classes for precisely this purpose, or so it seems. Are those not always present?
  • adamsmith
    I don't know, but even if they are, they wouldn't be the same for non-English catalogs, for a start.
  • marnenlk
    So how about using the displayed call number if we can find it through //[@class='fieldLabelSpan'][text()='Call Number: ']/[@class='subfieldData']/text(), and falling back to MARC if we can't?
  • marnenlk
    (Apologies if my XPath syntax is wrong. Hopefully my intent is clear, but I always need a reference in front of me to write XPath. :) )
  • adamsmith
    @aurimas - any concerns? The way I understand this, libraries get all their MARC from LoC, which is why the call numbers are sometimes wrong (sometimes slightly, as here, sometimes entirely, such as in Dewey systems like NUcat). So this would make sense and if we just test for it I don't think there's a way it could break anything.
  • aurimas
    Yeah, fine by me.

This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.

Sign In or Register to comment.