Author IDs

[fred-atherden]

Description

eLife supports ORCID IDs for authors. Erudit supports 3 other author IDs too: isni, researchid, scopus.

User stories

Author

• (1) As an author, I want to be able to see which, if any, ORCID ID has been associated with an author name so that I can check this information is correct.

Production staff

• (2) As production staff, I want to be able to see where an ORCID associated with an author goes so that I can check that correct page is linked.
• (3) As production staff, I want to be able to remove an ORCID ID from an author so that I can remove errors in ORCID attribution.
• (4) As production staff I need to be able to see whether an ORCID is authenticated so I can ensure the correct information is passed on to the downstream processes.

Erudit/PKP/SciELO

• (5) As QC staff, I want to be able to check which IDs have been associated with an author so I can ensure they are correct.
• (6) As QC staff I need to be able to see whether an ORCID is authenticated so I can ensure the correct information is passed on to the downstream processes.

But what if . . . ?

Considerations

• The ORCID ID display guidelines ask that the full URL is used, even though the number after https://orcid.org/ is a PID (persistent identifier) However, we believe for storage the content in the XML should be optimal for reuse and persistence and store only the ID (XXXX-XXXX-XXXX-XXX). For display purposes, it should be formatted with the ORCID url and the logo as defined by their requirements.
• Another ORCID display requirement is that their logo appears next to the full URL.
• For eLife ORCID IDs for authors will be exported from the previous system when they have been added using an integrated verification/login process, which means they require the additional attribute of @authenticated="true"; for PKP this will be a mixture and for Erudit they will not be. This attribute is required to differentiate.
• For eLife additional ORCID IDs should only be added to an article during proofing using an integrated verification/login process - due to validation requirements, production staff will not be able to add IDs manually, which means they require the additional attribute of @authenticated="true"
• We need to make sure that ORCID IDs added during proofing are attributed to the author they belong to - in the current proofing system, it’s possible to get an ORCID associated with the wrong author. We do this currently by clicking on the ORCID IDs, which are rendered as hyperlinks to the ORCID pages.
• eLife's production vendor should provide the ORCID login interface above Texture.

XML requirements

Should be captured as a <contrib-id>, as a child of <contrib>. All author ids MUST have an @contrib-id-type to identify which ID is being referred to. Accepted @contrib-id-type values are: orcid isni researchid scopus

Authenticated ORCID IDs require an attribute of: authenticated="true"

<contrib>
    ...
    <contrib-id contrib-id-type="orcid" authenticated="true">00000-0002-6048-1470</contrib-id>
    <contrib-id contrib-id-type="isni">00000 0004 6048 0000</contrib-id>
    …
</contrib>

Mock ups

Proposal

[michael]

The ORCID authentication is something that should be done in Libero as a separate step in the workflow that authors should perform. Texture is only there to read and write the XML, so there's no means to do this kind of verification process, as you could always just manually change the ORCID in the XML.

We can make Texture display a hint if the authenticated flag is set, and make the field read-only. With the only option to remove the authenticated ORCID, and fill in a new "unauthenticated" ORCID (to drive another workflow inside Libero for the author to verify).

[Melissa37]

The ORCID authentication is something that should be done in Libero as a separate step in the workflow that authors should perform. Texture is only there to read and write the XML, so there's no means to do this kind of verification process, as you could always just manually change the ORCID in the XML.

Agreed, Texture is not doing the authentication but storing the attribute that is provided on the XML input.

We can make Texture display a hint if the authenticated flag is set, and make the field read-only.

@NickDuf this is one for you too. In the context of all the info the author/QC staff see/action.

[michael]

@Melissa37 we've been discussing this, and think the automation part of authenicating ORCID's can not be part of the MVP. We would provide the necessary fields in Texture: ORCID with optional authenticated checkbox. That way you can edit all the needed data.

Later, this could be improved with a workflow in Libero to manage ORCID + authenticated flag. We would suggest to split this out into a separate feature-request called "ORCID authentication". That ok?

[eLifeProduction]

authenicating ORCID's can not be part of the MVP

Agreed.

Let's talk about this as I think there is a misunderstanding - the input into Texture would have authenticated attribute in the XML. I am not sure anyone should be able to change an ORCID in Texture if it's provided.

If something is authenticated, the ORCID should not be editable in Texture. If it's not authenticated it can be edited. That could be the "flag" to indicate whether something is authenticated or not and this is important to the workflow - if we can trust Texture will have the attribute if you cannot edit the ORCID?

I think we should discuss this as a group though.

[Melissa37]

That was my comment above - was logged into another production account