• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Connecting Researchers and Research

Sign in/Register
  • About
        • Our Mission
          • 2025 Vision
          • ORCID Trust
          • Annual Reports
        • Team
          • ORCID Board
          • ORCID Team
          • Work with Us!
        • Services
          • Member Portal
          • Annual data files
          • Member API
          • Public API
          • ORCID Registry
        • Governance
          • Bylaws
          • Board Elections
        • Policies
          • Privacy Policy
          • Dispute Procedures
          • Public Client Terms of Service
          • Open Source Project License
          • Public Data File Use Policy
          • Terms of Use
          • Brand Guidelines
  • For Researchers
        • Benefits for Researchers
        • Researcher FAQ
        • Video Tutorials
        • Sign in / Register
        • Get Help
  • Membership
        • Membership Benefits
          • Benefits for Funders
          • Benefits for Publishers
          • Benefits for Research Organizations
          • Benefits for Research Resources
        • Get Membership
        • Member List
        • ORCID Map
        • Membership Comparison
          • Basic Membership
          • Premium Membership
          • ORCID Consortia
        • ORCID Consortia
          • Consortia Agreement
          • Consortia Onboarding Checklist
          • Roles and Responsibilities of ORCID Consortia
  • Documentation
        • Features
          • Member Portal
          • Member API
          • Public API
          • ORCID Registry
          • Annual Data Files
        • Workflows
          • Journal Articles
          • Employment
          • Peer Review
          • Funder and Grants
          • View More
        • Integration Guide
          • Getting Started with Your Integration
          • Sandbox Testing Server
          • Registering a Member API Client
          • Integration and API FAQ
          • View More
        • API Tutorials
          • Get an Authenticated ORCID iD
          • Read Data on a Record
          • Add and Update Data on an ORCID record
          • Hands On with the ORCID API
          • View More
  • Resources
        • ORCID Community
        • Community Programs
          • Certified Service Providers
          • ORCID API Users Group
          • Historical Task Forces, Working Groups, and Steering Groups
        • Get Involved
          • Community Groups
          • Developers
          • Give Feedback
          • ORCID API Users Group
        • Member Resources
          • ORCID Enabled Systems
          • Publishers Open Letter
          • Funders Open Letter
          • Standard Member Agreement
          • Outreach Resources
          • Register a Sandbox API Client
          • Register a Production API Client
  • News & Events
        • News
          • ORCID News
          • Member News
          • Consortia News
          • Integration News
          • Blog
          • Release Notes
        • Events
          • Events Calendar
          • Webinars

Assertion Assurance Pathways: What Are They and Why Do They Matter?

June 13, 2018 By Robert Peters

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:

  1. Who made the initial iD-ID assertion (Assertion origin)?
  2. Did the Item origin add the information to the record?
  3. 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.

Blog

Filed Under: Release Notes

Primary Sidebar

Search

Sign up for blog updates

We will only use your email to notify you when we have new blog posts. You can unsubscribe at any time. See our Privacy Policy for more information.

Check your inbox or spam folder to confirm your subscription.

Recent Posts

  • 2020: A Look Back As We Venture Forward
  • New Integration – GIST
  • New Integration – University of Victoria
  • New Integration – Vidatum Technologies
  • New Integration – Mendel University in Brno

Blog Posts by Category

  • Consortia News (39)
  • Integration News (48)
  • Member News (30)
  • News (429)
  • ORCID News (192)
  • Release Notes (74)
ORCID logo

CC0 The text of this website is published under a CC0 license Images and marks are subject to copyright and trademark protection.

  • About ORCID
  • Privacy Policy
  • Terms of Use
  • Accessibility Statement
  • Contact us
  • Dispute procedures
  • Brand Guidelines
ORCID uses cookies to improve your experience and to help us understand how you use our websites. Learn more about how we use cookies. Dismiss