Google Scholar lookup engine takes first creator, should take author for book chapters

If you have a book chapter with Editor and Author, and editor is listed first, then the Google Scholar Search lookup engine will take the editor and plug it into the Google Scholar search string, with the result that nothing is found.

So this will not locate the chapter in question on Google Scholar:

Item Type: Book Section
Title: Define and Indefinite
Editor: Brown, Keith
Author: Abbott, Barbara
Date: 2006

Whereas this will:

Item Type: Book Section
Title: Define and Indefinite
Author: Abbott, Barbara
Editor: Brown, Keith
Date: 2006

The only difference being the order of Editor and Author fields in Zotero.

This is probably not limited to Google Scholar Search, but I haven't checked others.

Proposal: Lookup engines should take the first "Author"-type creator field when searching.
  • Any movement on this?
  • Just ran into this again. Should be a relatively easy fix, no?
  • It's an easy fix — I've done it locally — but it requires changing our OpenURL handling to use the best first creator for rft.aufirst and rft.aulast instead of first creator position. Anyone know if that's appropriate or will have other undesirable consequences?
  • By best you mean author > editor > translator > series editor > contributor ?
    I don't see how that could cause problems (on the contrary, I think that's preferable for all openURL requests, as mark suggests above)
  • edited July 7, 2016
    By best you mean author > editor > translator > series editor > contributor ?
    At the moment I have it coded to look for the first primary creator type for the item type (e.g., Author, Director, etc.), then an editor, and then to use the first creator position. I don't think it makes sense to prioritize a Translator over a Contributor if the Contributor is in first position.
    on the contrary, I think that's preferable for all openURL requests, as mark suggests above
    Well, Mark was talking about lookup engines, not OpenURL, which we use more broadly (e.g., to create COinS).
  • At the moment I have it coded to look for the first primary creator type for the item type (e.g., Author, Director, etc.), then an editor, and then to use the first creator position. I don't think it makes sense to prioritize a Translator over a Contributor if the Contributor is in first position.
    yes that makes sense.
    Well, Mark was talking about lookup engines, not OpenURL, which we use more broadly (e.g., to create COinS).
    Fair enough. Same answer, though. Where COinS is used as a metadata format, order shouldn't matter. Where it's used (which I understand was its principal original idea) to facilitate OpenURL requests, putting primary creators first should make it work better.
  • Fixed in the 5.0 beta.
  • Cool, thanks!
Sign In or Register to comment.