<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <link href="chrome://translator/skin/floatingPanel.css"
      type="text/css" rel="stylesheet">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    Great news ! Thanks !<br>
    <br>
    We are in the process of moving our current system to eprints. At
    the moment, I need to create the structure for our repository and
    develop export tools to get our current data to eprints. So, I'm
    more than interested in your author system. Your description of it
    seems to cover all our needs, and a few more... :-)<br>
    <br>
    If I can be of some help in testing with our 3.3.12 version, please
    let me know.<br>
    <br>
    Thanks again.<br>
    <br>
    Regards,<br>
    Gilles<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 10/07/2014 01:34, Matthew Brady a
      écrit :<br>
    </div>
    <blockquote
cite="mid:EMEW3|59c395c840c8a2eba44d0c608fb32a5fq690pv14eprints-tech-bounces|ecs.soton.ac.uk|193213813BA6574FBB1FEF6FD0D527D22D938D1E@EXCH-MBX-PRD-T2.usq.edu.au"
      type="cite">
      <pre wrap="">Hi All,

We have an author system up and running (95% working :) in 3.3.10 and 100% running in out prev 3.1.x version),

It handles a multitude of author related details, broken into two distinct groups, 
Author (the details about the person, including as many identifiers as you want/need, eg. alternate names, external id's (ORCID, Uni ID's anything really), email addresses etc..).
And
Author Instance (the details about that person for a point in time, Institution Affiliation, department affiliation (if reqd.) etc.
A single Author can have many Author Instances and the Author Instance ID gets placed into the creators 'id' field to tie it all together.  

This allows the 'cited' creators name, to be linked to an Author. (<a class="moz-txt-link-freetext" href="http://eprints.usq.edu.au/view/uniqueauthor/">http://eprints.usq.edu.au/view/uniqueauthor/</a>).
The instance record allows for collaboration reporting, internally, and externally between institutions.

I am in the process of cleaning it up, and pushing it out to Seb for possible inclusion into the main codebase, to give back to the community.  
It has taken longer that I am happy with to fix a few bugs found while upgrading to 3.3.10, but it all seems to be done.

Cheers

Matt.



-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:eprints-tech-bounces@ecs.soton.ac.uk">eprints-tech-bounces@ecs.soton.ac.uk</a> [<a class="moz-txt-link-freetext" href="mailto:eprints-tech-bounces@ecs.soton.ac.uk">mailto:eprints-tech-bounces@ecs.soton.ac.uk</a>] On Behalf Of John Salter
Sent: Wednesday, 9 July 2014 1:15 AM
To: '<a class="moz-txt-link-abbreviated" href="mailto:eprints-tech@ecs.soton.ac.uk">eprints-tech@ecs.soton.ac.uk</a>'
Subject: [EP-tech] Re: About compounds

I think that something that Seb demoed at the Eprints user group recently might be useful in this scenario...
*if* you had an author dataset, (similar to the 'user' dataset), you could store authors as dataobjrefs.

Seb's demo showed something similar for Projects/Funders - using a pop-up/modal window. It was very nice!

There has been previous discussion around the subject of richer data for authors - but I can’t remember any definite endpoint to those discussions!

Cheers,
John

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:eprints-tech-bounces@ecs.soton.ac.uk">eprints-tech-bounces@ecs.soton.ac.uk</a> [<a class="moz-txt-link-freetext" href="mailto:eprints-tech-bounces@ecs.soton.ac.uk">mailto:eprints-tech-bounces@ecs.soton.ac.uk</a>] On Behalf Of Ian Stuart
Sent: 08 July 2014 16:04
To: <a class="moz-txt-link-abbreviated" href="mailto:eprints-tech@ecs.soton.ac.uk">eprints-tech@ecs.soton.ac.uk</a>
Subject: [EP-tech] Re: About compounds

On 08/07/14 15:54, Gilles Fournié wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi,

The library staff wants us to describe authors with many fields 
(internal id number, department, unit, ...).

So we wonder if we can add subfields to existing compounds like 
creators or editors.
Obviously, we would keep existing subfields unchanged and just add new 
subfields.
Is it safe to do so ? Or are there risks to break something ?
</pre>
      </blockquote>
      <pre wrap="">Yes, adding extra fields is easy..... but only 1 level deep!


</pre>
      <blockquote type="cite">
        <pre wrap="">And, as a side question, I fear that a too big compound will be 
unusable
: in the input form, we will get a table with many columns, which will 
probably be larger than the screen width. Is there a way to have the 
subfields use several rows ?
</pre>
      </blockquote>
      <pre wrap="">I've not seen one.... not without writing your own rendering routines (which are eminently doable..)

</pre>
    </blockquote>
    <br>
    <div style="bottom: auto; left: 236px; right: auto; top: 142px;
      display: none;" class="translator-theme-default"
      id="translator-floating-panel">
      <div title="Cliquer pour traduire"
        id="translator-floating-panel-button"></div>
    </div>
  </body>
</html>