Getting author information from orcid API

[c-martinez]

At the moment, given name and last name and orcid are manually entered. It would save the user some typing if, when an orcid is provided, it could auto-complete given name and last name. This information could be pulled from orcid using their public API (maybe email and affiliation can also be retrieved).

Is there any reason NOT to do this?

[abelsiqueira]

I don't see any reason to NOT do this.
Do you know the orcid API? Can you give a hand with that?

[recap]

Just pulling the public-record.json (e.g. https://orcid.org/xxxx-xxxx-xxxx-xxxx/public-record.json) file of a user does not work client side cause of CORS.

[c-martinez]

I've played with the API before, I think I can figure out how to do this.

[c-martinez]

From the orcid API documentation, you need to generate a Client ID and secret, which you can use to generate a token:

curl --location --request POST 'https://sandbox.orcid.org/oauth/token' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=XXXXX' \
--data-urlencode 'client_secret=XXXX' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'redirect_uri=https://developers.google.com/oauthplayground' \
--data-urlencode 'scope=/read-public'

That yields a token, which is valid for 20 years or so (maybe we can do this only once even offline)

To get record information you can then use that token to call the /expanded-search endpoint:

curl --location --request GET 'https://pub.sandbox.orcid.org/v3.0/expanded-search/?q=orcid:0000-0001-8555-849X&rows=1' \
--header 'Content-type: application/vnd.orcid+json' \
--header 'Authorization: Bearer TOKEN'

Result looks something like this:

{
  "expanded-result" : [ {
    "orcid-id" : "0000-0001-8555-849X",
    "given-names" : "James",
    "family-names" : "Bond",
    "credit-name" : null,
    "other-name" : [ ],
    "email" : [ "james@mailinator.com" ],
    "institution-name" : [ ]
  } ],
  "num-found" : 1
}

[abelsiqueira]

I think the challenge that we discussed (@fdiblen and @recap, please clarify it this is not correct) is that we don't have a backend and therefore we can't store our TOKEN safely.

What if we ask the user for a TOKEN, and don't store it?
What if we ask ask the user to login, and using OAuth we get a TOKEN and don't store it?
Is any of this feasible?

[fdiblen]

Yes, we will need to think about how to do this. Maybe having a backend will help but it will be out of scope until we fix high priority issues.

[c-martinez]

Actually, I played with the API a bit more, and it turns out you can use the expanded-search endpoint without a TOKEN. So I don't think a backend is necessary at all.

[c-martinez]

Here a PR with a first attempt -- much work needed before it is anything sensible, but it is a start.

[recap]

@c-martinez Did you have success with the public api https://pub.orcid.org/v3.0/expanded-search/?q=orcid:.... Seems it is also blocked by CORS?

[recap]

never mind. seems to work!

[abelsiqueira]

The POC by @c-martinez is here: main...c-martinez:cff-initializer-javascript:orcid-api

[recap]

Part of the public object returned is an array of institution-name which is the union of education and employment so the first in the array is not necessarily the current person's affiliation. Emails array seems to be always empty. So it seems the only useful info we get is name and family name. Is it worth it to do an external api call for just name and surname?