There is a new service adapter/plugin in the Umlaut repo, for generating a link out to search Google Scholar for an identified article. It activates only for article-level OpenURL requests, and is generally expected to be configured to display only when no Umlaut-identified fulltext is available.
This isn’t in an Umlaut release yet, but if you want it right away you can easily copy the service plugin sourcecode into your local app. (You may want to copy a bit of CSS too).
What it does
“if no electronic version is found, offer to search for it in google scholar”
- Find It sometimes provides no full text for a citation, when the paper cited is actually available on the public web for everyone, as PDF or HTML.
- Because we don’t have a licensed copy, but it’s on the web for free
- Or, because we do have a licensed copy, but SFX failed to find it (possibly because insufficient metadata was included in citation), and it’s on the web for free too.
Google Scholar is pretty good at finding free copies of scholarly papers online.
So when Find It fails to find, the expert user often goes to Google Scholar to
check and see if there’s a free copy — but that requires manually going to google scholar, copy and pasting article title, etc. As well as knowing about Google Scholar.
So Umlaut can save the time of the reader.
Google Scholar has no API, all we can do is ‘blind link’ to it.
So it’s quite possible that Google Scholar _won’t_ have a free full text link, we
can’t know that in advance.
- The article might not come up at all in the Google Scholar search results
- The article might come up, but without a free fulltext link.
Even when Google does know about a free full text link, the Google UI is confusing, with many things that could confuse the user:
- * If the user clicks on the title of the link, they’re usually going to go to the publisher’s website, where they may or may not actually get access (if off-campus, almost definitely not).
- If the user clicks on the Find It link, they’re back to Find It where they started, in a potentially infinite loop.
- User has to recognize what a full-text link provided by Google Scholar looks like, click on that if there, and ignore the others.
Presented as ‘See also’ link
In general, one of the principles of Umlaut is not to present the user with links that might or might not get them to what they expect/want/were-led-to-believe, that might be blind alleys. Before we implemented Umlaut, too many of our interfaces led users to such blind alleys. Part of the point of Umlaut is to restore and build trust from our users in our services, as an efficient use of their time that is not going to lead them astray. And this Google Scholar link is going to confuse some users, I am sure — it’s not helping that Google Scholar’s UI that seems designed to lead users to the “pay us $30 for this” link rather than a free link, even when both are available.
However, in this case, almost any power user “in the know” is going to manually search Google Scholar when the link resolver fails to come up with fulltext. And it’s very inconvenient to have to do this manually, copy and pasting article title etc. I wish Google Scholar had an API, so we could do this with Umlaut’s usual attempts at “pre-checking” to see what’s on the other end of the link, but I decided it was still worth doing even though we can’t.
However, we’ve added the link to the right-hand “See Also” (“highlighted_link” type internally) space, where I think many people who aren’t specifically looking for it are not going to notice it — this subtlety was intentional.
And also added a little scare description: “This article may be available on the public web, look for links labelled[html] or [pdf]“. I don’t think that kind of “scare description” is the answer to everything, and I wouldn’t want too many of these polluting my page, but sometimes you gotta do what you gotta do.
(Of course, this Google Scholar link service can be configured to be included, or not included, in any particular institution’s Umlaut installation, it is of course optional).
From my own demo link resolver, these examples may not stay live and working forever, sorry.
Even in success scenario, user has to identify the full text link, not the other links that wont’ get them there.
example showing how things can fail
Here, Google Scholar does find _the article_, but it has no fulltext link. If the user clicks on the title, the publisher offers to sell it to them. If the user
clicks on the Find It link, they just go back to where they started. Kind of frustrating.