EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #07397

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

Sorry, but this whole "levels of trust" debacle sounds like splitting
hairs and dealing with a solution in search of a problem. Why in the
world would we be so paranoid about iDs of authors of scientific papers
being entered correctly and distrusting the unnamed librarian heroes who
do this job? (There are some reasons, mostly related to fully
machine-based "performance evaluation" aka counting papers and
references, which by itself is arguably not in the best interest of
scientists or science.)

As I see it, someone at ORCID made a poor decision regarding the
importance of "provenance" data by attempting to make a mere identifier
act like some sort of electronic signature for an assertion about
something. Not even having clearly specified the subject of the
assertion; nor technical means to verify that this "signature" is not
later tampered with in 3rd party repositories that store it - it's not
like the "authenticated" ORCID iD is cryptographically protected or
different from the "unauthenticated" one. Now this poor decision and the
resulting confusion has to be undone, which will probably turn out as
very difficult for political reasons - because it has already been
pushed onto ORCID's public agenda and, as we observe, is now seeping
through into implementations.

On 08/03/2018 01:06 PM, Alan.Stiles wrote:
> I think, ultimately, the situation you described previously:
> 
>  
> 
> I was reading this:
> 
> https://support.crossref.org/hc/en-us/articles/214567746-Authors-and-editors
> 
> recently - and wondering what the 'authenticated="true"' attribute
> 
> actually meant - and how the this assertion should be passed between
> 
> systems.
> 
>  
> 
> Makes a lot of sense and something along the lines of the display
> mechanism (from another previous discussion) shown here:
> 
> Authenticated: https://dblp.uni-trier.de/pers/hd/b/Bizer:Christian
> 
> Unauthenticated: https://dblp.uni-trier.de/pers/hd/b/Baierer:Konstantin
> 
>  
> 
> for entries we don’t explicity trust would be workable, with ORCID
> agreement.  Perhaps even a 3? level trust status – /“Locally
> Authenticated with ORCID”/, /“Directly from a Trusted 3^rd Party”/ (e.g.
> DOI), /“Derived from metadata”/  or something like those, so it is clear
> what level of trust can /should be put in the data.
> 
> We’re probably then in the realms of “who decides which 3^rd Parties to
> trust”, but at least then we’re not throwing away potentially valuable
> data, or having to create local user records for all authors with an
> ORCID in our systems.
> 
>  
> 
> In my head, if I pull a metadata record from e.g. Whiterose (cheers
> John!) which has a bunch of Locally Authenticated ORCIDS, I can include
> them as “Directly from a Trusted 3^rd Party”. Anything Whiterose has as
> Directly from a Trusted 3^rd Party could be downgraded for me as
> “Derived from metadata” (or I could go and get the data from DOI
> directly myself), and I can add any ‘Locally Authenticated’ for my own
> ‘connected’ user authors.
> 
>  
> 
> Any thoughts?  It seems worth an attempt at consensus amongst ourselves
> to then present a workable solution to ORCID for future improvements.
> 
>  
> 
> Alan
> 
>  
> 
>  
> 
> *From:*eprints-tech-bounces@ecs.soton.ac.uk
> [mailto:eprints-tech-bounces@ecs.soton.ac.uk] *On Behalf Of *Will Fyson
> *Sent:* 03 August 2018 11:17
> *To:* eprints-tech@ecs.soton.ac.uk
> *Subject:* Re: [EP-tech] ORCID Support Advance Update
> 
>  
> 
> To clarify, repository users do only have to connect their repository
> account to their orcid just the once, but I appreciate this is still a
> hurdle for busy academics and VIPs. And, as you say, for records with
> hundreds of authors where the record may be deposited in hundreds of
> repositories, emailing the external authors is not a sustainable solution!
> 
> The problem I think is ultimately described at
> https://members.orcid.org/api/member-api-credentials-check-list in the
> 'Mandatory Requirements' section, which explicitly prevents users from
> typing in ORCIDs. With this in mind I think the only options are to ask
> ORCID to change the requirments for using their member API (but this
> then erodes trust in their system) or we only allow external author
> ORCIDs to be added from other trusted systems, such as via a DOI (which
> will be possible when EPrints is better at storing where particular
> items in the metadata came from).
> 
> Will
> 
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Philipp Zumstein [philipp.zumstein@bib.uni-mannheim.de
> <mailto:philipp.zumstein@bib.uni-mannheim.de>] *Sent:* 03 August 2018
> 07:18 *To:* Eprints-tech *Subject:* Re: [EP-tech] ORCID Support Advance
> Update
> 
> Thank you all for the helpful comments to understand better how the 
> 
> trigger is technically working. I share some concerns about the 
> 
> practical workflows similar to Jan when it comes to importing from ORCID 
> 
> to our repository:
> 
>  
> 
> - The additional work with ORCID in our repository for our professors or 
> 
> other VIPs has to be minimal for them, e.g. 3-4 clicks. They certainly 
> 
> don't want to authenticate all the time or receive a tons of emails. 
> 
> Some of them are currently not personally adding publications in our 
> 
> repository, but that is rather a job for their secretaries. Moreover, we 
> 
> plan to add more data directly by our librarians.
> 
>  
> 
> - I completely understands that ORCID wants to control and ask for 
> 
> authentification about the data which is saved in their database, i.e. 
> 
> the data which is exported from the repository to ORCID. But I don't 
> 
> see, why they want to restrict the information which we save in our 
> 
> repository. The DOIs, ISBNs and ISSNs we add in our repositories are 
> 
> also not authenticated by the publishers or authors. Moreover, I can add 
> 
> my ORCID to my website or add it as part of my email signature by just 
> 
> copy and paste the number without any authentication.
> 
>  
> 
> - Sending emails to all authors for authentication sounds horrible. 
> 
> Imagine for example a paper with 1.000+ authors (e.g. from high energy 
> 
> physics) which ideally is saved in the repository of every author, which 
> 
> then would result in a huge amount of emails together. There is no 
> 
> incentive for the researchers to answer these emails and I guess that 
> 
> they would just categorized them as spam.
> 
>  
> 
> Best regards,
> 
> Philipp
> 
>  
> 
>  
> 
> Am 02.08.2018 um 14:10 schrieb Jan Ploski:
> 
>     These are very good points, John. I asked about this a while ago after
> 
>     an ORCID webinar at JISC, and there were no answers.
> 
>      
> 
>     The whole idea of "author-authenticated entry of ORCID iDs" seems rather
> 
>     misguided - like a short-sighted "overkill" technical solution to what
> 
>     is an organizational and data quality control problem. Just because you
> 
>     can do certain things using OAuth doesn't mean it's a good idea.
> 
>      
> 
>     In our repository much data entry is done by editorial staff, not by the
> 
>     authors themselves. We don't want to bother our authors (and much less
> 
>     external contributors) by email just to "sign off" the entry of their
> 
>     ORCID iD. This reeks of bureaucracy and would undoubtedly make it LESS
> 
>     appealing to integrate with ORCID. Needless to say, we won't use a
> 
>     plugin which forces that sort of workflow upon us.
> 
>      
> 
>     Add to this that authenticating just ORCID iDs alone does not really
> 
>     solve the data quality problem - just like one can make a data entry
> 
>     error in an ORCID iD, one can also make an error in an email or really
> 
>     any part of metadata - which obviously won't be automagically verified
> 
>     by ORCID or the author who confirms just that their iD is correct. In
> 
>     the end, the truth content of metadata is based on human dilligence and
> 
>     trust in quality control measures undertaken by the repository, not by
> 
>     some central external identity management system - which also
> 
>     constitutes a single point of failure from a distributed systems
> 
>     management viewpoint, and is a nuisance to repository users who now have
> 
>     to log in not just to the repository, but also to ORCID.
> 
>      
> 
>     In short, verifying by automatic lookup or some such that the ORCID iD
> 
>     entered is correct, is great, forcing authors to act as plugins to the
> 
>     data entry system really is not.
> 
>      
> 
>     On 08/02/2018 12:32 PM, John Salter wrote:
> 
>             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-editors
> 
>         recently - 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@ecs.soton.ac.uk
> 
>         [mailto:eprints-tech-bounces@ecs.soton.ac.uk] *On Behalf Of *Will Fyson
> 
>         *Sent:* 02 August 2018 10:59
> 
>         *To:* eprints-tech@ecs.soton.ac.uk <mailto:eprints-tech@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@concordia.ca
>         <mailto:Tomasz.Neugebauer@concordia.ca>
> 
>         <mailto:Tomasz.Neugebauer@concordia.ca>
>         <mailto:Tomasz.Neugebauer@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@ecs.soton.ac.uk
> 
>         <mailto:eprints-tech-bounces@ecs.soton.ac.uk>
>         <mailto:eprints-tech-bounces@ecs.soton.ac.uk>
> 
>         <eprints-tech-bounces@ecs.soton.ac.uk>
>         <mailto:eprints-tech-bounces@ecs.soton.ac.uk>
> 
>         <mailto:eprints-tech-bounces@ecs.soton.ac.uk>
>         <mailto:eprints-tech-bounces@ecs.soton.ac.uk> *On Behalf Of *Will Fyson
> 
>         *Sent:* July 11, 2018 10:16 AM
> 
>         *To:* eprints-tech@ecs.soton.ac.uk <mailto:eprints-tech@ecs.soton.ac.uk> <mailto:eprints-tech@ecs.soton.ac.uk>
>         <mailto:eprints-tech@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/
> 
>      
> 
>  
> 
>  
> 
>  
> 
> -- The Open University is incorporated by Royal Charter (RC 000391), an
> exempt charity in England & Wales and a charity registered in Scotland
> (SC 038302). The Open University is authorised and regulated by the
> Financial Conduct Authority in relation to its secondary activity of
> credit broking.
> 
> 
> *** 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/
>