Refworks sending bad DOIs in OpenURLs; fix in Umlaut?

So I just spent about a day diagnosing a weird issue where Refworks, in some cases, generates a bad OpenURL that prevents the link resolver from succesfully getting the user to fulltext.

The case that definitely triggers it is when your refworks citation was saved from a Refworks z39.50 search of pubmed, although there may be other cases.

The nature of the problem is that in the OpenURL field for DOI, Refworks doubles the actual DOI resulting in an illegal DOI.

For instance, if the actual DOI for the article is:

10.1016/j.vaccine.2012.11.026

Then instead of sending that in the DOI field, Refworks will send:

10.1016/j.vaccine.2012.11.026; 10.1016/j.vaccine.2012.11.026

While a human knows, oh, that’s the DOI twice… to software this is of course simply a bad/wrong DOI. And it results in SFX generating bad/wrong fulltext links.

(To make matters worse, both space and semi-colon are _technically_ legal characters to include in a single DOI).

I’ve not had much luck getting Refworks to acknowledge this problem or express any interest in fixing it. (It may be Pubmed “fault” for double-including a DOI in their z39.50 response, but it’s still Refworks using this data to send me a bad OpenURL, in my opinion. It’s not clear if Refworks has the same opinion. It’s not clear if they really understand what an OpenURL does, and that the DOI needs to be correct and machine-actionable, not just human-readable.).

But I realized I can get Umlaut to work around this with Umlaut’s ‘referent_filter’ feature. It would apply the fix just to incoming OPenURLs with Refworks sid’s, splitting on “; ” to restore the correct DOI.

I haven’t completely decided if I’m going to do this yet. I don’t like putting hacky workarounds in for other people’s problems, it generaly makes things fragile. And one of the downsides is that since “; ” are technically legal substring of a DOI, it _could_ mess up legitimate DOI’s that have that actual substring (presumably unlikely, but possible).

I also haven’t decided whether to do it just in my local app, or to contribute it to Umlaut code for all potential Umlaut users (and as default or a non-default option?).

But the fact that it’s possible for me to workaround the Refworks bug in Umlaut shows, to me, the value of having Umlaut as a layer where you can apply such interventions in ways agnostic to the underlying link resolver, and not requiring the underlying link resolver to support such customization directly.

About these ads
This entry was posted in General. Bookmark the permalink.

6 Responses to Refworks sending bad DOIs in OpenURLs; fix in Umlaut?

  1. Andy says:

    What if you split on ‘; ‘ and compared the two chunks (well, the *first* two chunks to be safe)? If they’re the same, you’ve got a doubled DOI; if not, it’s theoretically a legal DOI.

    Hacky, but a quick and probably safe hack.

  2. jrochkind says:

    Clever idea Andy, yep.

    On Wed, Feb 6, 2013 at 2:19 PM, Bibliographic Wilderness

  3. Hi Johathan, Did you contact RefWorks directly about this? I don’t see anything from you in our support email. Is this the issue with clicking on the openurl link in the catalog search results display page? If so, you have to import the references into your account before the openurl linking will work correctly. After they are imported into RefWorks the linking works just fine. Feel free to contact me directly at RefWorks Support if you have any questions or concerns.

  4. jrochkind says:

    Richard, yes, there are ongoing conversations with Refworks support (someone other than me here submitted a ticket), which are VERY confusing and I don’t want to add to the confusion by duplicating it here too.

    I will say that if Refworks is showing an OpenURL link, before the user has “imported into your account”, but you KNOW that does not work — I consider that a bug. I do not consider it acceptable to say “Well, yes, we show an OpenURL link before the user has imported into their account, but the user is not supposed to actually click on it, because we know it won’t work, if they do click on it, that’s a user error.” That is indeed one analysis that’s being promoted by some people, I do not consider it acceptable. You can not put an interface feature on screen that you know does not work, and then blame the user for activating it, and claim that’s a user error not a bug.

    But we are also seeing the problem after importing into account, yes.

    It is someone else at my institution that is engaging in dialog with Refwroks support not me, which, yes, is only adding to all the confusion.

  5. I just tested this from my RefWorks account at JHMI and I am unable to replicate. The FindIt linking worked fine. For the article you mentioned above I get the return…
    Find Article

    Article Title:
    Group B streptococcus vaccination in pregnancy: Moving toward a global maternal immunization program
    Author:
    Munoz,F. M.
    Journal Title:
    Vaccine
    ISSN:
    0264-410X
    Published:
    2012

    Can you send me a quick movie of the issue that you are seeing or perhaps a series of screenprints?
    Thanks

  6. It sounds like RefWorks is on it, which is good. In the general case, though — I say, work around the problem and document the crap out of it. If we in the library world always waited for vendors to fix their data / systems /whatever, well, pretty much nothing would work.

    So: fix, document, and complain bitterly and loudly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s