API 2.0: search use case in new API requires 11 calls instead of 1 on the old API

[bram]

Hi,

I really hope I'm missing something obvious here. Following these tutorials:

https://members.orcid.org/api/tutorial/search-orcid-registry

https://members.orcid.org/api/tutorial/read-orcid-records

it became clear that the search only returns the ORCIDS, and that additional calls are required to request more information on each of the individual ORCIDs.

We're re-implementing the following use case for DSpace:

A user of DSpace is submitting a new publication to the repository and wants to add authors. 

She fills out the name and hits the lookup button, that is used to identify if the author has an orcid, and to link the author to the publication.

In that case, we shoot the search query to ORCID, and what we need to display to the user is a list of names, so the user can verify if she found the right person.

In the old API, we were able to do this with a single search call, since all the necessary info came back in the list of search results.

If we now want to show a list of 10 authors, is it correct that we will need 11 calls?

one call to execute the search, followed by 10 calls, one for each individual ORCID that came back in the search results?

thank you!

Bram Luyten

Atmire

[Peters, Robert]

Bram,

You're not missing anything. We see that use case as an anti-pattern. Finding the existence of a name in the ORCID registry isn't enough to verify you have the correct ORCID iD. The following situations arise:

• There is more than one author with the same name listed, and more often then not the first plausible result is often incorrectly chosen.
• There is only one name listed, but in fact more than one author with that name exist in our database, however, the other(s) have chosen to keep their name private on the ORCID registry.  

Conveniently there is a blog post that explains this position eloquently: https://orcid.org/blog/2017/02/16/whats-so-special-about-signing.

While I realize this answer won't be fondly received I can say that ORCID staff is fond of DSpace and you are not the only repository with this sort of use case. So we are actively discussing viable means of helping curators get authenticated ORCIDs. Personally I'm involved in two separate projects aimed at the issue and hope to roll both projects out this summer.

Kindest regards,

Rob

Robert Peters

Technology Director at ORCID.org

Cellphone: +1.805.440.9056

Email: r.pe...@orcid.org

Skype: rcpeters

Timezone: PST
PGP/GPG/OpenGPG key: https://keys.mailvelope.com/pks/lookup?op=get&search=0x1519F37D99E18378

--
You received this message because you are subscribed to the Google Groups "ORCID API Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orcid-api-users+unsubscribe@googlegroups.com.
To post to this group, send email to orcid-api-users@googlegroups.com.
Visit this group at https://groups.google.com/group/orcid-api-users.
For more options, visit https://groups.google.com/d/optout.

[Bram Luyten]

Hi Robert,

thanks for the fast feedback. I agree with the two problems you noticed. To put it more frankly, our lookup is worthless if people don't expose their names and affiliations.

Hopefully if we pull in metadata from publishers or from orcid works, that already have the orcids in them in the first place, we'll need less manual lookups & author linking in the future.

If you have any more information to share about your ongoing DSpace projects, please do, we'd be highly interested.

On a sidenote, last year a group of repository managers discussed the different issues/challenges with the current integration. This resulted in several action points/JIRA tickets for DSpace.

You can find those findings here:

https://wiki.duraspace.org/display/cmtygp/DCAT+Meeting+December+2015

best regards,

Bram

Bram Luyten 250-B Suite 3A, Lucius Gordon Drive, West Henrietta, NY 14586 Esperantolaan 4, Heverlee 3001, Belgium atmire.com