While ORCID iDs and the ORCID API can fit within any aspect of the research and scholarship lifecycle, repositories are an especially relevant area of interest for many organizations in the ORCID US Community,  especially as the August 2022 White House Office of Science and Technical Policy (OSTP) memo on “Ensuring Free, Immediate, and Equitable Access to Federally Funded Research” confirms that ORCID iDs (digital persistent identifiers for individuals as specified by NSPM-33 Guidance) should be included in research outputs/repositories.

ORCID provides technical infrastructure that can be used in repository systems to improve author identification and streamline workflows related to information about works (publications, pre-prints, presentations, etc.). Author name dis-ambiguation and accurate attribution has been a challenge across the entire research and scholarly communication landscape, but with authors increasingly using ORCID iDs to identify themselves, organizations have been able to leverage the ORCID API (application programming interface) within repository workflows to disambiguate authors and ensure that individuals receive the appropriate credit for their contributions. 

Recommendations for Supporting ORCID in Repositories

In 2019, the “ORCID in Repositories Task Force” released a set of Recommendations for Supporting ORCID in Repositories, outlining a number of best practices for consideration when integrating ORCID iDs with repository workflows. Among other considerations, most importantly repository systems should:

  • Support collection of authors’ and co-authors’ authenticated ORCID iDs by using the ORCID API OAuth process (whereby individuals log in to their ORCID record and actively grant permission for the repository to get their ORCID iD, and optionally read data from and/or write data to their ORCID record). Any ORCID iD numbers that have been manually entered or obtained by searching the ORCID registry are not considered authenticated because there is room for error in those approaches. 
  • Support displaying ORCID iDs wherever user/contributor information is displayed. ORCID provides in-depth guidelines for displaying ORCID iDs. Note that ORCID iDs that have not been authenticated by the individual should be displayed slightly differently from those that have been authenticated.

Common Repository Systems & ORCID

The ease and logistics of using ORCID best practices for repositories varies significantly based on the specific repository software in use. Among the most common repository platforms in the US:

  • Bepress Digital Commons – a vendor system owned by Elsevier, the ORCID API is not included in the platform, so it is currently not possible to collect authenticated ORCID iDs in Bepress. Bepress customers are encouraged to voice support for ORCID API integration in Bepress by contacting them using our email template
  • DSpace – an open source community software system, authenticated ORCID iD collection depends on what version of DSpace is being used. DSpace version 7.3 and higher is a certified ORCID service provider, meaning that full ORCID member API functionality (ORCID iD authentication, reading data from ORCID records, and writing data to ORCID records) is built in and can be turned on using 1 ORCID member API key (see written documentation and video recording). While DSpace 6.x supports an author name look-up via the ORCID Public API, which obtains ORCID iDs through the unauthenticated approach of searching for author names in the ORCID registry, there is room for error (accidentally assigning the wrong ORCID iD to the wrong person), so this approach does not meet best practices. However, DSpace 6.x does offer a CSV upload workflow, which provides a work-around where authenticated ORCID iDs obtained from a different ORCID API system integration can be imported for display next to author names (see example from Duke University below). 
  • Esploro – a vendor system owned by ExLibris, Esploro includes ORCID Member API functionality out of the box that ORCID member organizations can activate using one of their ORCID Member API credentials, allowing authors to connect their authenticated ORCID iD to their Esploro profile (see documentation for how to enable the ORCID functionality). The development roadmap for Esploro includes enabling both writing information from Esploro to ORCID and reading information from ORCID to Esploro. For more details, contact Esploro.
  • Figshare – a vendor system owned by Digital Science, Figshare does not currently support collection of authenticated ORCID iDs. Rather, individuals can manually enter their unauthenticated ORCID iD to display with their Figshare user profile. However, plans are in place to implement ORCID authentication as well as the ability to import works information from ORCID to Figshare. On a side note, Figshare is set up to generate Datacite DOIs for each item submitted, with ORCID iDs included in the DOI metadata so that works can be automatically written to ORCID records via the Datacite Search & Link Wizard. See the Figshare blog and documentation for details.
  • Islandora – an open source community system, Islandora can be configured to allow users to log in with their ORCID iD, which enables the system to collect authenticated ORCID iDs. The ORCID module is not included upon install, but any Islandora site can make use of the feature. Currently, the module only allows for logging in with ORCID, not reading or writing data between Islandora and ORCID, but interested community members are encouraged to voice support for additional ORCID functionality in order to prioritize ORCID for development. For Islandora 7, the LASIR (Liberal Arts Sprint for Institutional Repositories) project also includes ORCID integration; see LASIR executive summary, GitHub, and the Islandora IR Interest Group page for more information.
  • Samvera – an open source community software system, ORCID authentication is not built-in, but can be achieved via customizations within a local Samvera instance. An ORCID microservice can also be implemented to gather authenticated ORCID iDs for Samvera repositories (see example from University of Virginia below). Additionally, an ORCID API integration is available for Hyku (see demo video).

Three Case Study Examples

The following case studies are designed to share insight and experience from repositories that have taken different approaches to integrate with ORCID to varying degrees, all using best practices. We hope to broaden awareness of the possibilities and encourage more usage and adoption of best practices for ORCID in repositories, so we can all benefit from the shared interoperable infrastructure that ORCID provides. 

  1. University of Virginia: Samvera 

The University of Virginia (UVa) has implemented a custom ORCID API microservice to not only collect and display authenticated ORCID iDs, but also to allow for writing works citations to individuals’ ORCID records from within University of Virginia’s Electronic Theses & Dissertations (ETD) repository and open institutional repository, both running on Samvera. Details about the ORCID integration and workflow can be found in our previous blog post on “ORCID & Samvera Institutional Repositories at the University of Virginia.” The UVa case study provides one of the most robust examples of ORCID API best practices functionality within institutional repositories at a university. In addition to ORCID connection via the repositories, UVa Library has also created an ORCID connector web page where researchers can create ORCID iDs and connect their ORCID iD to UVa as a trusted party at the same time.

  1. Duke University: DSpace

Duke University’s “DukeSpace” repository does not have an ORCID API integration built-in, but they are still following ORCID best practices by leveraging the built-in ORCID API connection in a different system used on campus, Symplectic Elements, which supports publication management and repository deposit and is connected with a VIVO-based campus wide profile system known as “Scholars@Duke”. The Elements ORCID integration allows users to connect their authenticated ORCID iD to their Elements profile, as well as match works information from their ORCID record and pull it into Elements, and write both works and employment information from Elements to ORCID. Authenticated ORCID iDs collected in Elements are then imported into DSpace through an RT2 crosswalk process, where they are stored, displayed next to author names in the DukeSpace repository (see example: https://dukespace.lib.duke.edu/dspace/handle/10161/17235), and linked as part of the repository identity metadata, involving only two metadata fields: author name and author name plus ORCID iD separated by a pipe, for example:

  • dc.contributor.author: Mangiafico, Paolo
  • duke.contributor.orcid: Mangiafico, Paolo | 0000-0003-2298-8120

If the author’s name string matches exactly a name in the ORCID field, the ORCID iD icon will appear next to the person’s name and link to the ORCID iD URI. 

DukeSpace provides a great example of how organizations can still utilize ORCID best practices in repositories without having a direct ORCID API integration with the repository itself. Duke is happy to share the specific DSpace code, RT2 crosswalk XML, etc. upon request. 

  1. Dryad Data Repository

The Dryad Repository is used internationally for datasets of all types and requires an ORCID iD to sign in and initiate the submission process. Dryad was the first repository to utilize an email workflow to collect authenticated ORCID iDs from co-authors, since the person submitting a dataset can only provide their own authenticated ORCID iD through the ORCID API OAuth process. As such, Dryad provides an excellent example of best practices for collecting authenticated ORCID iDs for multi-author works, or in a mediated deposit scenario:

Step 1: One author logs in to Dryad to submit a dataset, using their ORCID iD:

Once the author enters their ORCID login information, they will be asked to authorize Dryad Digital Repository to access their ORCID record as a trusted organization:

Step 2: When the dataset is submitted, only the ORCID iD for the submitting author will appear at first:

Step 3: When the dataset is published, Dryad sends an automated email to all listed co-authors, prompting them to add their ORCID iD to the dataset by clicking on a unique link that will launch them into the ORCID OAuth process: 

Step 4:  When a co-author clicks the link in the email, they are taken to Dryad to connect/authenticate their ORCID iD, at which point the ORCID iD is added to the Dryad metadata posted in schema.org and sent to DataCite to be included with the dataset DOI. The co-author ORCID iD also appears next to their name in Dryad:

For more information about ORCID and repositories or any of the featured case studies, contact orcidus@lyrasis.org.