PKP Sprint 2016: ORCID Integration
One of the groups in the very successful 2016 PKP Sprint tackled ORCID integration with OJS 2.x. This has long been an area of interest for our community.
We set ourselves several goals:
- Demonstrate basic interaction with the ORCID public API
- Facilitate accurate, guided collection of ORCIDs for authors and users
- Familiarize ourselves with various dimensions of the ORCID API, such as members API vs. public API, in preparation for later improvements
The ORCID API presents a lot of possibilities, divided between their public API (which our community will be able to use) and the member API (which is a little less certain, as membership probably won’t be common).
There are a few ways in which ORCID integration would serve our community well, a major one being that OJS could leverage ORCIDs to disambiguate between authors and users in OJS to accurately present information about a single author’s activity in OJS. OJS does not link author records between articles and its current approach to disambiguation is rudimentary. Beyond that, of course, OJS could break its own silo and present information about authors’ activities outside the single installation.
- Clinton Graham (University of Pittsburgh)
- Chris Maden (University of Illinois)
- Antti-Jussi Nygård (Federation of Finnish Learned Societies)
- Alec Smecher (PKP)
- Sean Xiao (University of Toronto)
Resurrecting Previous Work
We began by considering whether to implement ORCID integration as a plugin, or as a modification to the core code. Plugins can provide great encapsulation and portability but working on them sometimes involves jumping through hoops, and we were concerned about biting off too much work for a two-day sprint.
Clinton reminded us of the work he spearheaded at a sprint last year, resulting in a proof-of-concept plugin, so we decided to start with that code and see how far we could push it.
Moving Further Ahead
We begin with two fairly simple interactions:
- User Registration. When registering, users should be presented with an ORCID sign-in button. Following through the authorization process results in a registration form pre-filled with data from the user’s ORCID account.
- User Profile. When editing your user profile, permit the association of an ORCID.
Both of these tasks were fairly easy to implement with the help of ORCID’s excellent API documentation.
Our final goal, which we partially met at the sprint and completed afterwards, was to permit non-submitting authors to claim submissions made on their behalf. This is of extra importance because OJS doesn’t currently have any mechanism to cleanly link author records with users or with author records on other submissions from the same author.
We opted to implemented an email-based claim process. At the end of the submission process, emails are sent to authors without ORCIDs in their records; these emails include specially-formulated URLs that begin the ORCID authorization process and notify OJS of the author’s identity upon completion.
This feature in particular could lead to much smarter author disambiguation, and of course a data feed from OJS to ORCID to help complete ORCID’s database of author submissions.
The plugin resulting from this work is available at https://github.com/asmecher/orcidProfile.
We expect to work with partners to continue to develop this to add new functions and particularly towards supporting OJS 3.0 and OMP 1.2.
Many thanks to the sprint participants for demonstrating what a passionate and motivated community we are lucky to enjoy.