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:
Then instead of sending that in the DOI field, Refworks will send:
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.