Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
ORCID Update
And a recap…Sean MacRae, Business Systems Analyst, [email protected]
New Features
Through 15.0
New and Coming Soon
• New Editor ‘Change ORCID iD’ Edit permission• Already rolled out• Prevents Editors adding ORCID iDs via Search
• 15.0: Full ORCID API v2.0/2.1 compatibility• Behind the scenes
• 15.0: Custom Client Credentials• Affects who the User is told is requesting Access to their
ORCID record• 15.0: Review Deposit functionality
• Give reviewers credit, automatically
‘Change ORCID iD’ Permission
New sub-Permission of Search People. Remove it to keep NON-Authenticated ORCID iDs from entering your database.
‘Change ORCID iD’ Permission
Clearing it removes the ability to fetch, edit or delete ORCID iDse.g. on Search People – Update Information, shown here.
Custom Client Credentials
• EM is a registered ORCID Client• Users are asked to give ‘Editorial
Manager’ permission to read their ORCID iD.
• New in 15.0, journals can be configured with e.g. Publisher Client credentials
• User will then be asked to give the Publisher permission to access
• Will allow updates ‘downstream’
Your Name Here!
Custom Client Credentials
• Can only be set up by Aries Administrators• Publishers must have registered their own Client Application
with ORCID to obtain credentials• These are sent to Aries Client Services outside of EM• Publishers must register EditorialManager URLs as valid call-
back destinations when their credentials are used• For security; ORCID will only send users back to pre-
registered URLs• Contact Aries Client Services
Credit Review Activity
• With v2.0 of the API, ORCID supports Review Activities• *Only* client applications like EM can add these to ORCID
record• Requires one initial interaction with the Reviewer while logged-
in to get permission to update their ORCID Record• Thereafter, we can update their record any time• Initially, we’re sending basic details of each Review
• Journal (pre-registered)• Publisher• Date, Type and Role (all configurable by Review form)
Peer Review Activity at ORCID
Enabling Review Deposit
• Aries needs to configure ‘Review Group’ and ‘Convening Organization’ details, before Review Deposit can be enabled• i.e. ‘Review Group’ = Journal• ‘Convening Organization’ = Publisher
• Review Groups MUST be pre-registered with ORCID. We can retrieve details, e.g. by ISSN, if your publisher has done so• EM can also register a Review Group if necessary
• ‘Convening Organization’ Details are metadata sent each time• Contact Aries Client Services to enable and configure
EM configuration ensures that the Review is linked to the correct ‘Review Group’ in ORCID, and associated with the correct ‘Convening Organization’ when credited.
Review Credit Process
• We’ll ask reviewers ‘OK to send?’ when they submit each review• Informed consent each time
• One time, this will trigger an Authorization request• Gives us persistent permission to
update their ORCID Record
• We’ll send regular batches of completed reviews to ORCID• Can disguise actual dates
Review forms can include an Authorization to transfer to ORCID. This triggers a one-time ORCID Authorization the first time a particular Reviewer says ‘Yes’.
New Section on Review Form
Configuration: Review Form
Configuration: Deposit Policy
• You can choose to credit 1 review per submission, or all assignments• You can choose a daily, weekly, N monthly schedule• You can defer review deposit:• Until the author has been notified• Until the Final Disposition is set
Configuration: Deposit Policy
And a Second Chance UI for Reviewers
• A new ‘ORCID Deposit Authorization’ link added• Completed Assignments folder
• Displays only for eligible Reviews, not yet deposited• To allow reviewer to change
mind, or supply permission
ORCID Deposit Authorization page
• Reviewer can change mind• From ‘No’ to ‘Yes’, we will ask for authorization if necessary• From ‘Yes’ to ‘No’ only possible up to review deposit
• Allows recovery from failed deposit• If due to Access Token (permission to update ORCID record)
�
A Recap
Current best practices
Recap: Current Recommendations
• Collect ORCID iDs• Collect ONLY Authenticated
ORCID iDs• Reconfigure; remove options for
collecting non-Authenticated ORCID iDs
• Enable:• Registration fields (only)• Author and Co-Author validation• Review Deposit (soon)• ORCID SSO (Authors, Reviewers)
• Allows:• ORCID Registration (Authors)• De-Duplication (Editors, Authors)• ORCID drill-down (Editors)• Automatic ORCID Record Update
(Authors, Reviewers)
ORCID clearly identifies the source for any claimed work –self-claimed, or updated by a trusted party like Crossref
Why? Attribution we can trust
We automate the transfer of ORCID iDs to Crossref, which updates the Author’s record automatically (after a 1-time authorization via ORCID)
Why? Review Credit cannot be self-asserted
Why? ORCID records can help Editors
• E.g. when choosing a Reviewer, an Editor looks for experience• Past authorship• Past reviews• External information, reputation,
standing
• ORCID is not just an iD; there’s a profile behind it• ORCIDs shown in EM allow drill-
through to public ORCID Record• Should become source of all of the
above
Editor sees summary stats when searching for Reviewers
This person has very little history with the current publication
Reviewer Name drills-down to People Information
And the ORCID iD ‘drills down’ to the Reviewer’s public ORCID profile
Recap: Configuration Recommendations
• Add merge field to standard letters.• Ask users to supply their ORCID iDs if
they see link instead of an ORCID iD• Do NOT enable ORCID iDs for
Proxy-Registration by Editor• Maybe Expedited Reviewer Login
• Do NOT enable as Other Author fields• Use Co-Author Verification instead
• Restrict ‘Can Edit ORCID iD’ permission• To Admins, for ‘deceased author’ case
• Enable ORCID registration fields• Optional or Required for Registration?
Depends on your users• Automatically allows registration via
ORCID• Collect ORCID iDs on Submission
and Co-Author Verification• Make mandatory for submission if that
is publisher policy• Remove option for user to type in
their ORCID iD• You want ‘Authenticated’ ORCID iDs
• Enable ORCID SSO to encourage take-up
Recommendation: Registration Fields• PolicyManager>Edit Registration
Fields:• Collect ORCID as Registration Field
(maybe require?)• Force Users to Authenticate (not just
type or paste their own ORCID in).• ORCID Registration then available
as standard option• But you can make it the default• Any Register link will then go to
ORCID first.
‘Standard’ EM RegistrationUnlike simple metadata, an ORCID iD can be retrieved directly from ORCID
Register via ORCID
Pre-Registration layout depends on the ‘Ask users to register via ORCID by default’ setting, as well as sending the user to ORCID automatically
Users will see the same basic interaction as before, but we will retrieve more data
What is copied across?
• Given Name• Family Name• E-Mail address(es)• ORCID iD (Authenticated)• From Employment:
• Position• Institution• Department• City• State• Country
• Keywords Includes ‘Select Affiliation’ step for disambiguation
ORCID users control what is private; emails & affiliations must be set to be seen by ‘trusted parties’ or ‘everyone’ for EM to be able to read them
This allows us to pre-populate the registration page
Recommendation: Author & Co-Author ORCID• Configured by Article Type for
both:• Corresponding Author on submission• Co-Authors when they Verify
• Only seen if needed• i.e. missing Authenticated ORCID
• Can be Required for Submission• Good option is to make mandatory
for submission instead of registration
• Co-author verification ORCID request only optional• Use Co-Author Status to confirm
Corresponding Author can be asked for ORCID iD during submission process ifthey don’t have one
Uses the secure interactionCorr. Author Verification
This can be made a Requirement for Submission; so submission process cannot be completed without an ORCID iD
Corresponding Author Verification
The Co-Author ORCID request slots into the verification process, with or without registration, with or without a Questionnaire to complete
Co-Author Verification
Recommendations: ORCID SSO & Deep Link• PolicyManager>Configure Login
Page to enable ORCID SSO• Required to allow login to existing
record on e.g. Registration• Is helpful to users & can persuade them
to supply ORCID iDs
• PolicyManager>Edit Letters to add Authentication Deep Link to• Registration Confirmation• Submission Confirmation• Reviewer Invites/Instructions• Send Batch E-Mail• Remember: it confirms existing
Authenticated ORCID iDs
ORCID Single Sign-On is a benefit for users who submit to, or review for multiple sites
!
There’s an ORCID Authentication System merge field designed to be used in any letter; it confirms the ORCID iD if the user has one, and is a link if an Authenticated iD has not been retrieved
e.g. an annual ‘check your details’ batch letter
!
Why? Database Cleanup
• Journal office bugbear: cleaning up the duplicate People records• ORCID another item of metadata• Authenticated ORCID indicates
most recent active record• Special case: a non-Authenticated
ORCID iD does not prevent retrieval of a duplicate Authenticated copy
• But EM can now use ORCID iDs to warn users of their existing records• Reduce duplicates in the first place!
Search People: Merge people records is the EM mechanism for removing duplicate records
Cleanup: Merging
‘Existing Record’ check, during Submission
When a user retrieves an ORCID iD; we check for existing records. Looks like this author registered in order to submit but forgot a previous registration.
‘Existing Record’ Check during Registration
Had they registered with an ORCID, they would have found out even earlier – here the ORCID iD prevents an unnecessary registration
http://www.edmgr.com/[JOURNAL_CODE]/RegisterWithORCID.aspx
A new ‘Register’ link can be added to your Web site –this effectively combines Existing Person Check with ORCID SSO to route the user correctly
Note EM routes the user appropriately
Recommendations: Proxy Registration
• Configure Proxy Registration:• Sets the fields the Editor can
supply.• ORCIDs available
• We recommend keeping ORCID iD as ‘Hidden’ here• i.e. Don’t allow Editors to supply
the iD for someone else• Older functionality (curse of the
early adopter), deprecated• Rely on users retrieving own ORCID
iD – thus ‘Authenticating’ it
Recommendations: Proxy registration
• Configure Expedited Reviewer Login:• Sets the fields the Reviewer must
supply if the Editor did not
• Make the ORCID Required to get the Reviewer to supply it• Is this desirable for Reviewers?
Probably not – most journals ask from Authors only
• Also uses main Edit Registration Field Setting to ‘Force Users to Authenticate’.
• i.e. not just type or paste it in
Editor Proxy-Registers
Editor supplies some initial details –a configured sub-set of all registration fields. So the ORCID iDcan be included here but we recommend not.
EM then asks the Reviewer for fields Required from them and not already supplied by the Editor
Expedited Reviewer Login
The End!� Fin�
Content Slide
• Text• Text
Section Header Slide
Section Header Subtitle
Section Header SlideSection Header Subtitle
“Two Content” Slide
• Text goes here • Text goes here