An assertion is defined as a confident and forceful statement of fact or belief, or the action of stating something, or exercising authority, confidently and forcefully.
How is this relevant to ORCID, you might ask? ORCID enables connections between individual researchers (via their ORCID iD) and their activities and affiliations (via other identifiers and APIs), which are asserted — either by the researcher, or with their permission, by ORCID members.
Anatomy of an ORCID Assertion
While assertions might seem straightforward, things can get complicated quickly. We care about three relationships in an assertion. The Item origin, the Assertion origin, and the Source. Whoever published the activity or is the affiliated party is the Item origin. Whoever collects the ORCID iD and makes the connection to an item is called the Assertion origin. Whoever adds the information to the researcher’s ORCID record is called the Source. The “who” in these sources may be the same or different from each other. Here are some real-world examples:
- All the same. Some universities collect iDs from employees and students, connect the iDs to the person’s local personnel record, and then update the person’s ORCID record with information about their affiliation with the university. In this case, the Item origin (affiliation), the Assertion origin (connecting the iD and affiliation), and the Source (updating the ORCID record) are the same member organization.
- Same origin, different source. Some journals collect iDs, connect them to an author’s publication (item), and then pass these assertions to the DOI registrars Crossref or Datacite, who in turn assert that information into the author’s ORCID record. In this case, the journal is both the Item Origin and Assertion Origin, and Crossref/Datacite is the Source.
- All different. Researchers can claim their existing papers and datasets using a search and link wizard. In this case, the Assertion origin is the researcher, and the Source is the wizard. The item origin is usually a third party that hosts the paper or dataset (such as a journal or repository).
When the “who” is different, researchers may be asked for permission multiple times in a single workflow, which can be confusing and leads to information drops and disconnects between the initial collection of their iD and updating of their record. This is a problem. We are developing “On Behalf Of” functionality (OBO) to better describe assertions and enable researchers to share permissions across multiple systems in a single workflow. OBO will enable our members to correctly reflect who has made which assertion – the researcher, the member, or another organization acting on behalf of either the researcher or the member.
Traceability and Trust using Persistent Identifiers (PIDs)
In ORCID’s ideal world, all assertions made in ORCID records would include a persistent identifier (PID) as a component of the item (publication, dataset, affiliation, etc.) connected to the ORCID iD. Specifically, we would like that PID to be resolvable and meet the FAIR data/metadata principles. We call this a “trusted PID”.
When trusted PIDs are not practical (as in the case of affiliation assertions for which no PID currently exists), for the purposes of traceability we require additional metadata to enable manual assurance of the assertion. Over time, we expect that trusted PIDs will emerge for all assertions.
Assertion Assurance Pathways
Given these complexities, what are the best pathways to ensure traceability of ORCID assertions? We propose an assurance model based on three factors:
- Who made the initial iD-ID assertion (Assertion origin)?
- Did the Item origin add the information to the record?
- Can the item PID be resolved to an ORCID iD in the upstream metadata, and when the PID is resolved does it provide an an easy assurance pathway? In other words, is the PID used a trusted PID?
Here are three example pathways:
- Trusted PID. A university that is an ORCID member organization collects permissions from a researcher and updates that individual’s ORCID record with an affiliation item. This item includes the university’s organization PID, an affiliation PID that resolves, affiliation role, affiliation dates and an authenticated ORCID iD. Together, these item data meet the FAIR principles and provide a high amount of assurance in both human and machine-readable format.
- PID. A researcher adds affiliation information to their record through the user interface, selects the name of their organization from the provided list, and manually enters role and dates. This item will include a unique organization identifier, but no affiliation PID. To achieve a high amount of assurance one would need to contact the affiliated organization and verify the details.
- No PID. A researcher adds affiliation information to their record through the user interface and manually enters the name of their organization. To achieve a high amount of assurance one would need to disambiguate the organization name provided (“Marlboro College” UK or “Marlboro College” USA?) and then contact the organization to verify the details.
Having Fun Yet?
We can map assertion origin with PID types into a 3 x 3 matrix and identify patterns to help manage assertion assurance. From this, we are developing “On behalf of” functionality which will help provide traceability to Assertion Origin. Look for more on assertions and assurance when we launch this functionality with the release of our new API 3.0. If you have any questions in the meantime, please let us know.