[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] ORCID Support Advance Update



That's correct - the ORCID Support Advance plugin wouldn't delete any 
ORCIDs once the circumstances described in your email below are met. 
However, as I mentioned in my previous email, the Advance plugin won't 
delete automatically anyway as this functionality is disabled by 
default, but it would stop you from editing the ORCIDs by making the 
field read-only.

With regards to permissions, these are decided by the user when they're 
connecting their repository account to their ORCID account. The user is 
given the option to select if they want the repository to be able to 
"Create and update activities on your ORCID record" and to be able to 
"Retrieve restricted details from your ORCID record".

Many thanks,

Will


------------------------------------------------------------------------
*From:* Tomasz Neugebauer [Tomasz.Neugebauer at concordia.ca] *Sent:* 02 
August 2018 22:01 *To:* Eprints-tech *Subject:* Re: [EP-tech] ORCID 
Support Advance Update

Thank you for this useful information, I really appreciate it!

If I understand correctly, then, in order not to lose the ORCIDs for 
authors collected through ORCID Support plugin, we would have to do the 
following:

?Ensure that every ORCID in an author field matched on the email field 
with a user profile record.  This would require adding the ORCID id to 
user profiles and/or the email address to the author field whenever 
ORCID is included.

If that is done, then the ORCID Support Advance plugin will not delete 
any of these ORCIDs, right?  What sorts of permissions will it assign to 
them?

Best wishes,

Tomasz

Thank you also to Will, Jan and John for the broader discussion about 
ORCID IDs that I do believe we need 
(https://twitter.com/photomediathink/status/1012051960676212738). If we 
are going to promote ORCID, it has to make sense as a system.  If we can 
only refer to ORCID IDs of authors who have an account on our IR, then 
we would need another global identifier for the other authors that we 
can?t use an ORCID for.

*From:*eprints-tech-bounces at ecs.soton.ac.uk 
<eprints-tech-bounces at ecs.soton.ac.uk> *On Behalf Of *John Salter
*Sent:* August 2, 2018 7:14 AM
*To:* eprints-tech at ecs.soton.ac.uk
*Subject:* Re: [EP-tech] ORCID Support Advance Update

Hi Will,

Thanks for that clarification - I was a bit worried there for a moment!

I think the ORCID landscape is shifting from a 'get people to sign up 
for an ORCID' to 'sharing the data sensibly/properly'.

We are a key part of that!

Cheers,

John

*From:*eprints-tech-bounces at ecs.soton.ac.uk 
<mailto:eprints-tech-bounces at ecs.soton.ac.uk>[mailto:eprints-tech-bounces at ecs.soton.ac.uk] 
*On Behalf Of *Will Fyson
*Sent:* 02 August 2018 12:03
*To:* eprints-tech at ecs.soton.ac.uk <mailto:eprints-tech at ecs.soton.ac.uk>
*Subject:* Re: [EP-tech] ORCID Support Advance Update

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 at leeds.ac.uk <mailto:J.Salter at leeds.ac.uk>] 
*Sent:* 02 August 2018 11:32 *To:* Eprints-tech *Subject:* Re: [EP-tech] 
ORCID Support Advance Update

>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.

This concerns me. We (repository developers) shouldn't be encouraging a 
blinkered approach to ORCIDs (or other persistent identifiers).

You wouldn't exclude a DOI for a paper if it wasn't minted by your 
institution - so why would you choose to discard ORCIDs for non-local 
members?

If the ORCID has come from a trustworthy upstream system (e.g. CrossRef, 
PubsRouter), then the ORCID should stay with the author.

Local ORCIDs can supplement this data - so a record harvested from your 
repository is 'improved'.

I was reading this: 
https://support.crossref.org/hc/en-us/articles/214567746-Authors-and-editorsrecently 
- and wondering what the 'authenticated="true"' attribute actually meant 
- and how the this assertion should be passed between systems.

If a **trusted** upstream system states that an ORCID is authenticated - 
can we as a consumer of that data also state that the ORCID is 
authenticated when relaying data from our system?

The ORCIDs should be seen as an 'additive' set of data - if your system 
can state that an author now has an ORCID - do it.

Just don't throw away data that already exists for non-local authors.

Cheers,

John

*From:*eprints-tech-bounces at ecs.soton.ac.uk 
<mailto:eprints-tech-bounces at ecs.soton.ac.uk>[mailto:eprints-tech-bounces at ecs.soton.ac.uk] 
*On Behalf Of *Will Fyson
*Sent:* 02 August 2018 10:59
*To:* eprints-tech at ecs.soton.ac.uk <mailto:eprints-tech at ecs.soton.ac.uk>
*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 at concordia.ca 
<mailto:Tomasz.Neugebauer at concordia.ca>] *Sent:* 01 August 2018 17:50 
*To:* Eprints-tech *Subject:* Re: [EP-tech] ORCID Support Advance Update

Hi everyone who has installed the ORCID Support Advance plugin, Will?

I am still looking to get a clearer picture of what I can expect to 
happen when I install the ORCID Support Advance plugin on top of the 
ORCID Support plugin that we currently have working.

What will happen to the ORCID ID?s that we have already collected in the 
author field of publications?

The description from Will below about ORCIDs from a DOI import says this:

?, 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. ?

Does the above also apply to any ORCIDs that we have been collecting 
using the ORCID Support plugin?

I don?t think that our depositors have been diligently filling in the 
email column in the author field during the deposit process, does that 
mean that the user profile lookup will fail and the ORCID will be 
deleted for any author that doesn?t have an email listed in the author 
column?

When does this deletion happen, during indexing? Is there any way to 
prevent it from happening?

Thanks so much for any insight or advice on this is really appreciated.

Tomasz

*From:*eprints-tech-bounces at ecs.soton.ac.uk 
<mailto:eprints-tech-bounces at ecs.soton.ac.uk><eprints-tech-bounces at ecs.soton.ac.uk> 
<mailto:eprints-tech-bounces at ecs.soton.ac.uk>*On Behalf Of *Will Fyson
*Sent:* July 11, 2018 10:16 AM
*To:* eprints-tech at ecs.soton.ac.uk <mailto:eprints-tech at ecs.soton.ac.uk>
*Subject:* [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




*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech

*** Archive: http://www.eprints.org/tech.php/

*** EPrints community wiki: http://wiki.eprints.org/

*** EPrints developers Forum: http://forum.eprints.org/



*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech

*** Archive: http://www.eprints.org/tech.php/

*** EPrints community wiki: http://wiki.eprints.org/

*** EPrints developers Forum: http://forum.eprints.org/



*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20180803/1e57dc0b/attachment-0001.html