Group DOIs with case insensitive comparison to resolve works duplication
I think that when comparing the DOIs of works to decide what to group, you aren't parsing them to be case insensitive using ASCII case folding for comparison of text.
The doi:10.1002/14651858.CD001730.pub3 is equivalent to doi:10.1002/14651858.cd001730.pub3
but Scopus and CrossRef are using these two different presentations, which then list as separate works in ORCID.
Although in this this case I can create a manual entry with the Scopus ID and the DOI as listed by CrossRef, I shouldn't have to and the Scopus presentation of the DOI is the one preferred by the publisher.
Thanks for your suggestion to improve the ORCID Registry.
Currently the ORCID Registry processes all identifiers as being case sensitive. This is a known issue — some identifiers are case sensitive, whilst others are not.
Our team recognize this issue and will be addressing it by cataloguing our identifiers, their case sensitivity, and other validity issues, then putting these into effect and potentially sharing some of the data in the identifiers API (https://pub.orcid.org/v2.0/identifiers/ ).
We currently have looking into the identifiers scheduled to commence April 2017 and shall update you when we are further into the project.
ORCID Community Team
Baptiste Cecconi commented
Any news on case insensitive DOI matching ?
Reposting Israel Hanukoglu's comment in a related thread (https://support.orcid.org/forums/175591/suggestions/3342355):
> I confirm the problem reported by Stuart Ray on March 17, 2017.
The duplicate records in ORCID is a very serious problem that should be fixed.
Reposting Stuart Ray's comment from a related thread (https://support.orcid.org/forums/175591/suggestions/3342355), on March 17, 2017 4:32 PM:
> It appears (from my profile) that the DOI merge function fails to match (and merge) duplicates when there are differences in DOI capitalization from different sources (e.g. Scopus vs. ResearcherID vs. CrossRef).
Many thanks for your notice -- it is the same issue as above, and we have started gathering the information we'll use to address this and related issues.