[Web4lib] FW: Troubleshooting Google Scholar Resolver, JSTOR
metada and 360 Link
Campbell, James (jmc)
jmc at virginia.edu
Thu Apr 23 17:48:44 EDT 2009
FWIW, I replied to Renata off list that this is not an issue with 360 Link as a resolver. We have no problem going from Google Scholar to JSTOR via 360 Link. That said, given how hard it is to get information out of Google, Serials Solutions may be her best chance to get it fixed, whatever it is.
- Jim Campbell
Digital Access Librarian | Librarian for German
University of Virginia Library | Charlottesville, VA 22904-4112
513 Alderman | campbell at virginia.edu | 434-924-4985
From: web4lib-bounces at webjunction.org [mailto:web4lib-bounces at webjunction.org] On Behalf Of Bob Duncan
Sent: Thursday, April 23, 2009 4:52 PM
To: Dyer, Renata; web4lib at webjunction.org
Subject: Re: [Web4lib] FW: Troubleshooting Google Scholar Resolver, JSTOR metada and 360 Link
At 07:49 PM 4/22/2009, Dyer, Renata wrote:
>We subscribe to Serials Solutions 360 Link service and have, amongst
>other resources, linked JSTOR and Google Scholar holdings to it.
>The problem we are experiencing as of February this year is that
>when JSTOR holdings are recognised by the Scholar, the 360 Link is
>bringing up a citation screen containing only title and a weird
>looking DOI and and error message saying DOI is invalid. JSTOR
>support confirmed that the Scholar is misinterpreting article
>metadata (read: DOI) and that they will try to resolve it with
>Serials Solutions and Google.
>In the meantime my patrons are clicking on the Google Scholar link
>that shows an error citation screen and does not take them to a full
>text as it should! Of course if they click on the linked title
>they'll go straight to the JSTOR article but we tried so hard to
>train our client to use the Findit link in Scholar every time they
>see it and now they are having this very frustrating experience.
>Is anyone else experiencing problem with JSTOR holdings and other
>Open URL resolvers?
Short answer: no.
Long answer: I'm not sure I understand the problem, and the above is
confusing on many levels, but it sounds like your problem has little
to do with JSTOR and mostly to do with your 360 Link
implementation. (Assuming 360 Link works like most other OpenURL
resolvers and SS hasn't cut some special deal with GS.)
- Google Scholar does not "recognize" JSTOR or any other holdings
you may have. The institutional_holdings files you provide to Google
Scholar indicate journals and dates, but not providers, and is used
by GS soley in the determination of whether or not an OpenURL link
will be generated for your users. GS has no knowledge of your JSTOR access.
- Clicking your Findit link sends the OpenURL generated by GS to
your implementation of SS 360 Link, so what happens in the 360 Link
window is a result of what 360 Link does with the metadata in the GS
OpenURL. If you've told GS you can deal with DOIs, the OpenURLs you
get from GS for articles that have DOIs tend to have the DOI and
little else. It's up to your OpenURL resolver to deal with this
situation; either it needs to be able to link to the article using
the DOI provided, or it needs to submit the DOI to CrossRef (or
whatever), get metadata back, and use that metadata to create links
to the article.
- In my experience, GS does not include "weird looking" DOIs in its
OpenURLs, but it does create version 0.1 OpenURLs, so if 360 Link is
expecting to see (e.g.) rft_id=info:doi/10.1063/1.44091, but it gets
id=doi:10.1063/1.44091 instead and doesn't know what to do with it,
you may indeed get something odd looking in place of a valid DOI.
Can you provide an example search result in GS where the DOI seems
off and where you see odd behavior that you think is JSTOR-specific
and not related to Google Scholar's horrible implementation of
OpenURL or 360 Link's possible shortcomings? (And if you could
provide the Google Scholar OpenURL for the result too, it would be
helpful to see what's going on with your resolver. The library link
for "Treasury Department (Australia)" in GS preferences is not
selectable from here so it's impossible to see what you're seeing.)
Robert E. Duncan
Editor of IT Communications
Easton, PA 18042
duncanr at lafayette.edu
Web4lib mailing list
Web4lib at webjunction.org
More information about the Web4lib