EPrints Technical Mailing List Archive
Message: #09044
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
Re: [EP-tech] orcid support advance
- To: David R Newman <drn@ecs.soton.ac.uk>, "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
- Subject: Re: [EP-tech] orcid support advance
- From: Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca>
- Date: Wed, 31 Aug 2022 12:19:38 +0000
CAUTION: This e-mail originated outside the University of Southampton.
Hi David,
Thank you for all of that context. You summarized the issue very well. It seems like it will be impossible to assign any new ORCIDs in the creator field, unless they were already there in the autocomplete from a time that is prior to the orcid support advance
plugin.
The script that you wrote sounds like an excellent solution overall! Something that runs nightly and fills in any matching authenticated ORCIDs into the creator fields makes sense to me. I also think that it's what users/depositors are expecting, an "automatic"
populating of that field for their deposits, once they give the repository the required permissions.
I hope you will share your script soon, and when you do, I plan on using it.
Best wishes,
Tomasz
________________________________________________
Tomasz Neugebauer
Tel. / Tél. 514-848-2424 ext. / poste 7738
Mailing address / adresse postale: 1455 De Maisonneuve Blvd. W., LB-540-03, Montreal, Quebec H3G 1M8 library.concordia.ca From: David R Newman <drn@ecs.soton.ac.uk>
Sent: Tuesday, August 30, 2022 4:03 PM To: eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>; Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca> Subject: Re: [EP-tech] orcid support advance Attention This email originates from outside the concordia.ca domain. // Ce courriel provient de l'exterieur du domaine de concordia.ca
Hi Tomasz, I believe that the ORCID Support Advance plugin makes the ORCID column for creators/editors read-only, as this is required by ORCID, so you don't get inconsistent data with the same creator/editor with different ORCIDs. Beyond making the
ORCID field read-only the creators/editors field will behave the same as with just ORCID Support. This provides the /cgi/users/lookup/name script [1], which incorporates the ORCID in the autocomplete with the name and ID (typically email) fields. This works
by looking up previous entries for creators/editors. I assume this is the point you are trying to make, which is that before your installed ORCID Support no creators/editors would have ORCIDs so it is likely this lookup script will find the name, maybe ID
(email) but probably not an ORCID, so this is pretty useless, unless you can backfill the existing creators/editors.
An alternative solution to the /cgi/users/lookup/name script
would be to have a lookup script that gets the name, ID (email) and ORCID from the EPrints user table. This will get populated with the ORCID when the user connects their EPrints account with ORCID, although their name maybe be formatted differently
to how it appears in the creators/editors field, (typically user field has full given name whereas creators/editors may use initials). It may be worth submitting a GitHub issue requesting such a script is written. The disadvantage of such a script is that
you would need to have a decent of number of users in your repository to make this useful. Even if you have all institutional users added to your repository, you will have to manually add external creators/editors names in full. This could lead to inconsistency
and would be annoying for someone having to manually add a regular collaborator, when before they could make use of auto-complete. One thing I have written to improve ORCID Support is a cron job that can run periodically (I run overnight) that looks up any EPrints user that has a valid ORCID set. It then looks up all eprint records that have a creator/editor where the
email address (or whatever field) of the user matches the creators/editors ID. It will then set the ORCID sub-field for that creator/editor to that or the user record, if it does not yet have a value set. This script is quite useful when you have ORCID Support
Advance, as it will makes sure a user who has connected their EPrints user account to ORCID that day will get all their eprints updated with ORCIDs that night. This is something you would want to do asynchronously, as you could have hundreds of eprints that
need updating. I have not yet provided this script, (probably best added to ORCID Support), as if it does not work properly it could do quite a bit of damage. However, I have been running it on several repositories for a while now, so I am fairly confident
it is sound. When I have a chance I will try submitting this as a pull request to the eprintsug/orcid_support GitHub repository. Regards David Newman [1]
https://github.com/eprintsug/orcid_support/blob/master/cgi/users/lookup/name On 30/08/2022 8:09 pm, Tomasz Neugebauer via Eprints-tech wrote:.
|
- Follow-Ups:
- Re: [EP-tech] orcid support advance
- From: Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca>
- Re: [EP-tech] orcid support advance
- References:
- [EP-tech] orcid support advance
- From: Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca>
- Re: [EP-tech] orcid support advance
- From: Tomasz Neugebauer <Tomasz.Neugebauer@concordia.ca>
- [EP-tech] orcid support advance
- Prev by Date: Re: [EP-tech] orcid support advance
- Next by Date: Re: [EP-tech] orcid support advance
- Previous by thread: [EP-tech] Sort view with creators_name and corp_creators
- Index(es):