ORCID Authorities: Updating author profiles to their ORCID equivalents

[Sean Carte]

Is there a way to link existing authors with their ORCID equivalents?

In a DSpace 6.3 repository, using Mirage2 xmlui with several thousand authors, we are considering enabling ORCID authority control, but won't this lead to the creation of duplicate authors?

I have an author with 31 publications on the repository, but when I create a new submission and lookup the author's name, I can find it on ORCID, but it says 'items in this repository: 0'.

If I use the ORCID id to submit the item, the browse index then lists the author's name twice, once with 31 publications, and once with 1 publication.

Even if I rebuild the discovery index: dspace index-discovery -fb, the two apparently identical author's names continue to be listed separately.

If I submit a new item using the name from the ORCID index, a subsequent search looking up that author's name still finds the name in the ORCID index (italicised) with 'items in this repository: 0', but now there is also a non-italicised name with a link to view items. Following that link takes me to the recently deposited item, but no others. So it looks like I've now got three versions of the author: the original, the ORCID id, and the newly created one.

I'm not sure what I'm doing wrong, but surely this can't be right.
--

[emilio lorenzo]

hi Sean

first guess is that the two entries ("the browse index then lists the author's name twice")  belongs to entries with different confidence levels  (200 vs 500 or so...) . The Index separates entries if confidence values are not the same (there are substantial difference between values)  if one of  them do not reach enough  "confidence"

Second guess (I prefer this)...   the authors in you current index has a given "internal" authority key and Orcid validated authors enters into the repository with "orcid id" as the key..  So, different keys, different entries

Some time ago we developed for EUI´s Cadmus repository a method for joining entries belonging to different validation sources.  There was a communication to OR2019 explaining this.

Best luck

Emilio

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/CA%2BxAuhP_mnGm0Y7Wax10n6yPusN6efOvT_AomhDX9YtGkB4r3g%40mail.gmail.com.

[Sean Carte]

Thanks for the input, Emilio.

It seems that in this repository all the authors have been entered using dc.creator rather than contributor.author.

I suppose I'm going to have to find a way to move all the authors into contributor.author fields before any of this can work.

--

[Nurminen, Miika]

On 3.3.2020 15:51, Sean Carte wrote:
> It seems that in this repository all the authors have been entered
> using dc.creator rather than contributor.author.
>
> I suppose I'm going to have to find a way to move all the authors into
> contributor.author fields before any of this can work.

Hi Sean,

This is probably not a recommended way compared to e.g. CSV-files or
REST updates but if modifying the database directly is an option (e.g.
during a service break with backups in place just in case), the fastest
way to accomplish this would be a SQL update, e.g.

UPDATE metadatavalue SET metadata_field_id=[dc.contributor.author]
WHERE metadata_field_id=[dc.creator id];

where [...]s are numeric ids retrievable from the metadata registry
(e.g. in our database dc.contributor has id 1 and dc.contributor.author
has id 3).


Good luck,
Miika Nurminen

[Sean Carte]

My thoughts exactly. Thanks, Miika.

--