Apologies, my previous email was a little bit flippant on this issue! I agree we need to try and store authenticated ORCIDs wherever possible. To that end we're working on adding an annotation system so that where an ORCID is imported from a trustworthy upstream system, this bit of provenance is stored and we know not to try and check this ORCID against a user account.

The alternative approach would be to introduce a notion of guest/external users to EPrints so that when external authors are added we can store the fact that this user was added via a trustworthy upstream system and we have an actual user object for them.

Ultimately I believe ORCID themselves would prefer the idea that the repository emails the external author and so the author can authenticate their ORCID - this too would no doubt be easier to do with a guest/external user type, but should the ORCID plugin(s) be introducing new user types and muddying the user dataset?

Many thanks,

Will

From: John Salter [J.Salter@leeds.ac.uk] Sent: 02 August 2018 11:32 To: Eprints-tech Subject: Re: [EP-tech] ORCID Support Advance Update

Hi Tomasz,

The ORCID Support Advance plugin does only allow ORCIDs to be stored against creators/editors if they can be matched to a user via the 'Email' column in all circumstances (to facilitate the read-only nature of the field). Therefore ORCIDs added through use of the ORCID Support plugin are affected by this too.

When we've been installing the Advance plugin on repositories we've been encouraging administrators to tidy up their ORCID data so that the ORCIDs stored are matched with user profiles. This naturally poses a problem for storing ORCIDs for external authors, but in my experience most repositories are happy storing ORCIDs for just their own users.

If an email isn't present in the creator/editor field, but an ORCID is, the ORCID would be removed the next time the EPrint is recommitted. The ORCID Support Advance plugin contains a pre-commit trigger that updates the ORCID field based on the email column to help keep the record up to date. These triggers are disabled by default when the plugin is installed however to prevent any accidental erasing of data by installing the plugin. (the fields are read-only upon installing the plugin however and so until the triggers are re-enabled the content of the creator/editor ORCID fields is essentially fixed.)

I hope this helps answer your questions!

Many thanks,

Will 

From: Tomasz Neugebauer [Tomasz.Neugebauer@concordia.ca] Sent: 01 August 2018 17:50 To: Eprints-tech Subject: Re: [EP-tech] ORCID Support Advance Update

Hi Everyone,

A couple of minor updates have been applied to the ORCID Support Advance plugin, bringing it up to version 1.3.2.

The updates are only very minor, fixing issues where the plugin was generating a few too many messages in the indexer and error logs. A Change Log documenting these most recent changes is available at https://wiki.eprints.org/w/ORCID_Support

Regarding the discussion a couple of emails above in the EP-Tech list ("Import by DOI in ORCID plugin"), a new DOI imported that takes ORCIDs into account is not available at present. Due to the requirements that the ORCID field must be readonly when connected to the member API so that ORCIDs can only be added via an authoritative source, the ORCID field that is added to the creator/editor tables cannot be edited. Therefore to stop values from being entered, which then later cannot be removed, the ORCID field uses the creator/editor 'Email' column to lookup user profiles in the repository that have connected to orcid.org so that the creator/editor ORCID field can be verified. As such any ORCID added via a DOI import, might then be erased if the user profile lookup cannot be made.

This is an issue we're looking into resolving however and so hopefully we should have some updates on it in the future!

Many thanks,

Will