Learning Patience: Taking a Step Back on Affiliation Assertion Requirements

Laure Haak's picture

ORCID is committed to enabling traceable connections between researchers and their activities and affiliations.  This includes using identifiers for things (such as DOIs) and places (such as organization identifiers), as well as people. In many cases, however, identifiers are not yet widely used. In some cases, there is not yet an understanding that identifiers are needed.

When we first launched affiliation functionality in 2013 (see Organizational Affiliations Now Part of ORCID Record), our focus was on organization identifiers.  These made it possible for us to create an organization pick list for researchers to choose from when adding employment and education affiliation information to their ORCID record.  Since then, researchers have used this pick list to make over 5m such assertions, and increasingly their institutions are using the ORCID API to add affiliation information for their own researchers – to date, researchers have given permissions for over 100K such assertions.

However, what about researchers who have more than one affiliation at the same institution, over time or at the same time?  In this case, simply connecting a person’s ORCID ID with an organization ID is not enough. And even with additional role metadata, there is no clear way to resolve the affiliation: to find a web page or other independent digital information for that affiliation.  Some institutions have faculty and staff profile pages, but by and large these pages are removed when a faculty member moves to a new organization. And let’s not even ask about students, who most often don’t have any online representation hosted by their institution.

As part of our push toward trusted assertions (see Assertion Assurance Pathways: What Are They and Why Do They Matter?), we decided that our new API release candidate (3.0) should require affiliation assertions added to an ORCID record by any source to include either a persistent identifier – which we knew was a stretch – or, what we thought was achievable now, an affiliation start date.  Verifying that someone has ever worked at institution X is significantly harder than verifying that they worked at X during a particular time period.

However, thanks to your feedback on our new API release candidate, we now know that, for many in our community, this bar is currently too high. So, by popular request, we are temporarily rolling back the start date/identifier requirement for affiliations in API 3.0. We will be taking time over the next 6-9 months to work with the community to gain a better understanding of your workflows and information sources and to engage with partners to test approaches.  If you are interested in working with us on this project, please contact me.

In the meantime, we will be:

  1. Displaying “date created” for items on the ORCID record and in the API
  2. Requiring organization IDs for the asserting organization and the affiliation itself
  3. Ensuring that only those organizations that have a direct relationship with the affiliation may post it to the ORCID record.  This means that Institution X may ONLY post affiliations pertaining to their institution. We will be managing this using organization IDs for the asserting organization and the affiliation being posted
  4. Encouraging (but not requiring) the use of start dates in affiliation assertions
  5. Encouraging pilot integrations that test use of identifiers for the affiliation
  6. Encouraging inclusion of a local webpage URL (such as a faculty or staff profile) in the affiliation assertion, preferably in an archived format (see e.g., https://www.webcitation.org)

Our Engagement team will be responsible for working with members to ensure these guidelines are communicated, and also adhered to in our Collect & Connect badging processes.

We look forward to working with our community to improve transparency and trust in affiliation assertions. Please contact us if you have questions or suggestions.

Related ORCID posts

1ORCID API Versioning