Since 2013, ORCID records have supported two connection types between researchers and organizations: education and employment. We call these “affiliation assertions”. They can be added to the record directly by the record owner or by an ORCID member organization they have shared their iD with.
Organizations are already asserting education and employment, and are now becoming interested in asserting other kinds of affiliation – such as membership, editorship, and certifications. We are therefore proposing to update our data model, using a simple set of affiliation types that can model the widest range of activities, while also minimising potential overlap between types. Streamlining API and integration upgrades is also a major priority. We need to ensure that the requirements of our community are satisfied within these constraints. The end goal is to create an affiliation model that supports community requirements, and that is easily understandable by researchers, end users, and API clients.
With all this in mind, our draft proposal (also available in PDF) describes the following affiliation types:
Employment: This affiliation type is unmodified. It captures formal paid employment relationships, such as staff, researcher, faculty or contractor.
Education and Qualifications: Education is expanded to capture completed academic study, training, professional qualifications, and certifications.
Honorary Positions and Awards: This new type captures distinctions bestowed upon an individual, such as prizes, honorary degrees, or fellowships.
Membership and Service: This new type encompasses society or professional association membership, as well as affiliations that lie outside of formal employment, such as editorial service, committee service, or election to a Board.
We would value your feedback before implementing these changes in our API and user interface. We are interested in hearing from you about which subtypes should be made available, example affiliations, the use cases for them, and their international applicability. Feedback on the overall approach, the top level categories, and the use of a fixed list of subtypes is also welcome. In your comments, please consider the following:
- Do the categories make sense to you?
- Are the subtypes useful?
- What is missing from the list?
- What shouldn’t be here?
- What distinctions are made in your locale?
- What issues does this model present?
You may comment directly in the document, or via email to the ORCID API users group or our community team. Please submit your comments by November 20, 2017.
