<html><body>
<p><font size="2" face="sans-serif">User not equal creator! User accounts are in most cases submitter accounts, which aren't the same persons (usually research group secretaries, e.g. in a research environment) than the authors (researchers). There are usually way more (factor 10-100) different creators in a repo than user accounts.</font><br>
<br>
<font size="2" face="sans-serif">The BORIS repo of University of Bern has an ORCID implementation written by Peter West.</font><br>
<br>
<font size="2" face="sans-serif">However, as John or Lizz suggested, storing ORCID in the creators_id or a subfield doesn't solve the normalization problem the current EPrints data model has.</font><br>
<br>
<font size="2" face="sans-serif">The current data model just supports an 1:n relation between bibliographic (eprint) records and authors.</font><br>
<font size="2" face="sans-serif">This may result in duplicate and mismatching names (and e-mail addresses), leading to various problems (name searches finding only subsets of publications, creation of incomplete publication lists, IRStats2 statistics with non-aggregated subsets, to name a few). To give some indication of the severity of the problem: The ZORA repo has about 75K records with 280K authors, of which 110K are unique names (which are not unique persons). Using some matching algorithms and additional criteria, we can reduce these to about 77K persons with unique names.</font><br>
<br>
<font size="2" face="sans-serif">The current data model also requires that one would have to enter the ORCID of a given author for every publication. This is wrong.</font><br>
<br>
<font size="2" face="sans-serif">The relation between publications and authors is n:m (many-to-many).</font><br>
<br>
<font size="2" face="sans-serif">Library catalogs solve this by providing an authority file for authors and a join table that connects publications and authors. In the authority file, attributes such as name variants (e.g. Sir Elton Hercules John = Reginald Kenneth Dwight) , date of birth and death, IDs such as ORCID can be stored. ORCID must be entered only once: One per author.</font><br>
<br>
<font size="2" face="sans-serif">Martin</font><br>
<br>
<font size="2" face="sans-serif">--</font><br>
<font size="2" face="sans-serif">Dr. Martin Brändle</font><br>
<font size="2" face="sans-serif">Zentrale Informatik</font><br>
<font size="2" face="sans-serif">Universität Zürich</font><br>
<font size="2" face="sans-serif">Winterthurerstr. 190</font><br>
<font size="2" face="sans-serif">CH-8057 Zürich</font><br>
<br>
<font size="2" face="sans-serif">mail: martin.braendle@id.uzh.ch</font><br>
<font size="2" face="sans-serif">phone: +41 44 63 56705</font><br>
<font size="2" face="sans-serif">fax: +41 44 63 54505</font><br>
<font size="2" face="sans-serif"><a href="http://www.id.uzh.ch">http://www.id.uzh.ch</a></font><br>
<br>
<img width="16" height="16" src="cid:1__=4EBBF75CDFDCA82A8f9e8a93df9@lotus.uzh.ch" border="0" alt="Inactive hide details for Justin Bradley ---16/01/2015 15:16:27---I’d add it to the user records instead, so any creators_id v"><font size="2" color="#424282" face="sans-serif">Justin Bradley ---16/01/2015 15:16:27---I’d add it to the user records instead, so any creators_id value can be associated with the user and</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">Von: </font><font size="1" face="sans-serif">Justin Bradley <jb4@ecs.soton.ac.uk></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">An: </font><font size="1" face="sans-serif">eprints-tech@ecs.soton.ac.uk</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Datum: </font><font size="1" face="sans-serif">16/01/2015 15:16</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Betreff: </font><font size="1" face="sans-serif">[EP-tech] Re: ORCiD</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Gesendet von: </font><font size="1" face="sans-serif">eprints-tech-bounces@ecs.soton.ac.uk</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="3" face="serif">I’d add it to the user records instead, so any creators_id value can be associated with the user and the user.orcid.</font><br>
<font size="3" face="serif">Obviously that depends on if you are modelling users, or just creators without user IDs.</font><br>
<font size="3" face="serif">Justin</font><br>
<br>
<font size="3" face="serif">On 16 Jan 2015, at 14:09, John Salter <</font><a href="mailto:J.Salter@leeds.ac.uk"><font size="3" color="#0000FF" face="serif"><u>J.Salter@leeds.ac.uk</u></font></a><font size="3" face="serif">> wrote:</font><br>
<ul style="padding-left: 36pt"><font size="3" face="serif">Hi,<br>
How is anyone storing an ORCiD in EPrints?<br>
<br>
Out-of-the-box, EPrints has creators with a name component, and an id component.<br>
The default name of this field is 'Email':</font><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="https://github.com/eprints/eprints/blob/3.3/lib/lang/en/phrases/system.xml#L396"><font size="3" color="#0000FF" face="serif"><u>https://github.com/eprints/eprints/blob/3.3/lib/lang/en/phrases/system.xml#L396</u></font></a><font size="3" face="serif"><br>
<br>
I was thinking or using it to store the ORCiD instead of the email address, but didn't know if any 'best practice' was emerging yet?<br>
<br>
Cheers,<br>
John<br>
<br>
<br>
<br>
*** Options: </font><font size="3" face="serif"><a href="http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech">http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech</a></font><font size="3" face="serif"><br>
*** Archive: </font><font size="3" face="serif"><a href="http://www.eprints.org/tech.php/">http://www.eprints.org/tech.php/</a></font><font size="3" face="serif"><br>
*** EPrints community wiki: </font><font size="3" face="serif"><a href="http://wiki.eprints.org/">http://wiki.eprints.org/</a></font><font size="3" face="serif"><br>
*** EPrints developers Forum: </font><font size="3" face="serif"><a href="http://forum.eprints.org/">http://forum.eprints.org/</a></font></ul>
<br>
<font size="3" face="Helvetica">--<br>
Justin Bradley<br>
Senior Software Consultant</font><font size="3" color="#0000FF" face="Helvetica"><u><br>
</u></font><a href="mailto:jb4@ecs.soton.ac.uk"><font size="3" color="#0000FF" face="Helvetica"><u>jb4@ecs.soton.ac.uk</u></font></a><font size="3" face="Helvetica"><br>
EPrints Services<br>
Bay 2, 3081, B32<br>
University of Southampton<br>
<br>
<br>
<br>
</font><br>
<tt><font size="2">*** Options: </font></tt><tt><font size="2"><a href="http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech">http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech</a></font></tt><tt><font size="2"><br>
*** Archive: </font></tt><tt><font size="2"><a href="http://www.eprints.org/tech.php/">http://www.eprints.org/tech.php/</a></font></tt><tt><font size="2"><br>
*** EPrints community wiki: </font></tt><tt><font size="2"><a href="http://wiki.eprints.org/">http://wiki.eprints.org/</a></font></tt><tt><font size="2"><br>
*** EPrints developers Forum: </font></tt><tt><font size="2"><a href="http://forum.eprints.org/">http://forum.eprints.org/</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</body></html>