Research resources include user facilities such as laboratories, repositories housing special collections, specialist equipment, and other resources that researchers request permission to use.This workflow sets out a process by which a typical research resource proposal submission system can integrate with the ORCID API, including receiving authenticated ORCID iDs from researchers, retrieving data from ORCID records, adding research resource access items (and the resultant outputs) to ORCID records, and updating items which you have previously added to ORCID records. This workflow requires ORCID API 3.0.
The ORCID-enabled workflow described here requires a touchpoint with the researcher where their ORCID iD can be collected using an authentication process. This would typically be during a specific proposal process or when the researcher is requesting credentials to access the resource. We also strongly recommend that the sponsoring organization connects information about use of their resource to their researchers’ ORCID records, so that it can be shared -- with permission -- with other organizations, such as their institution, publisher, or funder.
Sponsoring organizations that implement this workflow stand to benefit from improved acknowledgement of resource use and a better understanding of the impact of the work undertaken by researchers using them. Researchers also benefit from the transparent, reliable connections with funders, publishers, and research institutions that will enable them to easily share their resource awards. Resource-hosting organizations can also make the reporting process more straightforward and reliable by embedding identifiers in the application process, and by creating and sharing connections between users and resources.
Research resource items appear on the record like this:
There are many types of research resources, from single-use reagents to international collaboratives with dedicated facilities. ORCID supports a high-level model that can link to other places for domain specific detail. There are four high-level resource types:
A facility, building, or other physical space used to perform research
Neutron spallation source, animal facility, data enclave, archaeological site, telescope array. ships, planes, farms, laboratories
|Collection||An object or group of objects used for research purposes; can be tangible or digital||
Ocean mission, field campaign, collaborative data sets or resources, rare book collection; museum collection, biological specimen collection
|Equipment||Hardware used for research purposes||
Microscope, computers, glassware, samples, materials
Services used for research purposes
Proteomics analysis, computing services, data analysis, logistical support, legal services, copyediting, expert or staff advisement
In addition to resource type, a research resource item within an ORCID record contains the following information (* indicates required items):
- Proposal/Registration Title*. This is the main display field for research resources e.g., “Neutron Beam Award” or “Beam time and computing resources”
- Proposal/Registration ID*. This is the public identifier (DOI, PURL, etc.) for the proposal or request to use the resource. Ideally, this identifier should be persistent and resolve to a public landing page with information about the proposal or request, such as an awards database or resource user log.
- Proposal Host(s)*. This is the organization that receives and processes resource proposals or requests. Proposal Host may be the same as Resource Host
- Proposal Host Name*
- Proposal Host Organization iD*. This is the public identifier (one of GRID, Ringgold ID, Open Funder ID, LEI) for the organization managing the proposal or request process
- Resource(s)* (up to 100)
- Resource Name* - e.g., “Neutron Spallation Source”
- Resource ID(s)* - from an extensible list of acceptable PID types (e.g. RRID, DOI, URI)
- Resource Type* - one of ‘Infrastructures’, ‘Collections’, ‘Equipment’, or ‘Services’
- Resource Host(s)* This is the organization that administers or operates the Resource, such as a national laboratory, government agency, or research university
- Resource Host Name*
- Resource Host Organization ID*
- Proposal URL for general information about the resource use
- Proposal Start Date
- Proposal End Date
Typically, a research resource workflow will follow the pattern described below, although this can vary depending on the specific use case. This example is based on a researcher submitting a proposal to access a research resource. The components of the integration are: authenticate, display, collect, connect, and synchronize.
- The researcher starts the proposal submission process for the resource provider (an ORCID member)
- The resource provider authenticates the researcher’s ORCID iD, requests permission to interact with their record, and stores that permission For technical information on authenticating using Oauth please refer to our documents.
- The resource provider collects data from the researcher’s record using the ORCID API and uses it to help populate the proposal application form
- When a proposal is accepted, the resource provider adds information about the proposal and the research resources being used to the researcher’s ORCID record, connecting the person with the infrastructure
- The resource provider includes link between the ORCID iD and the proposal within their own system, displaying the connection in the appropriate pages.
- The resource provider retains the ORCID iD and associated permissions in order to update the researcher’s record in future, as needed, synchronizing the two systems. This could include adding proposal outputs such as data or articles, or updating research resource access
- (Optional) The resource provider uses the link between infrastructure and ORCID iD to help discover related outputs and track the impact of their research resources
It is critical that you collect ORCID iDs and obtain permission to read and update ORCID records, by first prompting users to sign into ORCID from within your system, and then retrieving their data from the ORCID Registry using the ORCID API. It is also essential to provide information within your system about why you are collecting ORCID iDs and why this is beneficial to your users.
You must provide a hyperlinked ORCID-branded button for collecting authenticated ORCID iDs: This can be at sign-in, within the researcher’s personal profile, or in a customized email to a researcher. Using an ORCID-branded button consistently helps ensure that researchers associate it with being asked to securely provide their iD, which in turn builds trust in ORCID as a reliable identifier.
You can help your researchers get credit for their invited positions and distinctions by connecting validated information about their affiliation with you to their ORCID records. At the same time, you will be helping to build trust in scholarly communications. By asserting the connection between individuals and your organization -- connections that only your organization can make authoritatively -- you ensure that your organization is appropriately acknowledged when your employees and affiliates make professional contributions. That information can then be shared, with the researcher's permission, with the other systems they interact with, helping to create a trustworthy research information infrastructure.
Adding information to ORCID records involves sending formatted data to the ORCID Registry using the ORCID API, and saving the put code that the ORCID Registry returns for each item. Doing this requires that you have collected both ORCID iDs and update permission as described in Authenticate above.
Displaying ORCID iDs clearly signals to your users that your system supports ORCID. It requires you to have collected validated ORCID iDs from researchers as described above in Authenticate. To complete the Display process:
Once a researcher has connected their ORCID iD to your system, publicly display their iD on their profile within your system so that they know that they have successfully connected and asserted their iD. Format the iD as a hyperlinked URI and include the green iD icon, per our iD Display Guidelines. Also include the authenticated iD in any metadata sent to third-party services when applicable.