EPrints Technical Mailing List Archive

Message: #03813

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: ORCiD

*apologies for butting in*

There’s a couple of aspects to this splitting/bundling that I think we (eprints geeks) need to consider:

1.       Relationship between packages (you can have a researchdata repository, but do you want simple authors, or the *really good* ones?)

2.       Migrating existing data into the new model

 

I think that we are part way down the route for (1), but I haven’t seen any discussion around (2).

e.g. How would I go from my current random list of names applied to EPrints, to using a new ‘real author’s package?

Is this something that  has been pondered somewhere?

 

Cheers,

John

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Adam Field
Sent: 20 January 2015 12:10
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: ORCiD

 

Hi Matt,

 

            Developing this into an installable package (ideally a bazaar package) would be the sensible way forwards.  We're in a process of identifying pieces of functionality like this in EPrints and breaking them out into installable packages to be able to create releases of EPrints for specific purposes (publications, data, open education, etc).

 

            Would you be interested in working with me to wrap this up into a bazaar package?  I have a large supply of extra voodoo that can be applied to this problem.

 

--

Adam

 

On 20 Jan 2015, at 01:02, Matthew Brady <Matthew.Brady@usq.edu.au> wrote:



Hi all,

 

We wrote code based on vanilla ePrints code, trying to keep data structures as similar as possible.

Added in workflow definitions and Plugins and handlers for screens etc.

 

It’s quite possible that it could be built as a bazaar module/component, but that was extra voodoo I didn’t want to get into at the time J

I expect incorporating it into a vanilla product may be a better option, as many institutions/locations appear to need an author identity

 

I have attached a .pdf with the general workflow and sample screenshots from one of our dev machines. 

Gilles and I are the test users in this case, as it was doco I wrote in Aug when Gilles was testing some functionality.

 

 

Matt Brady

Application Engineer

Phone: +61 7 4687 5713

 

 

-----Original Message-----
From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Field A.N.
Sent: Monday, 19 January 2015 8:36 PM
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: ORCiD

 

Hi Matt

 

          This is really interesting.  How do you manage your two user datasets?

 

          As to integrating the code into EPrints, please send me the zip file, and I'll start moving things forwards.  This may be something that can be built into a bazaar package.

 

--

Adam Field

Business Relationship Manager and Community Lead EPrints Services

 

 

 

 

On 18 Jan 2015, at 22:38, Matthew Brady wrote:

 

> Hi Ian, everyone else..

> 

> We have our system with 2 extra datasets (Author and Author Instance)

> 

> The author contains everything about the person including 1 to many

> identifiers. (google scholarID, scopusAuthorID, ORCiD, etc etc

> etc....) The author instance contains a link to a point in time, their

> affiliation with institutions/dept etc etc

> 

> The instance ID is then stored in the vanilla creator_id field.

> 

> This allows a single unique author to be displayed, along with all their cited versions of their name, so the citations render correctly, and still get assigned to the correct person.

> (Example image also displays the statistics icon, which links to that

> authors stats page. – from

> 

> <image001.png>

> 

> I have tried to get this pushed into the ePrints Core, but Seb hasn’t got back in touch about who to send it to.

> 

> I would like it incorporated into the base product, so we all have the same version, rather than a dozen or more splintered versions of code all trying to do the same thing.  This will make the support on this email list more fruitful, if we are all on the same page.

> 

> If anyone knows who is maintaining the base ePrints codebase these days, let me know and I will forward on the .zip file of all the code we have for inclusion into the base product.

> 

> Cheers

> 

> Matt

> 

> 

> -----Original Message-----

> Sent: Saturday, 17 January 2015 2:01 AM

> Subject: [EP-tech] Re: ORCiD

> 

> On 16/01/15 14:09, John Salter wrote:

> > Hi, How is anyone storing an ORCiD in EPrints?

> >

> > Out-of-the-box, EPrints has creators with a name component, and an

> > id component. The default name of this field is 'Email':

> > em

> > .xml#L396

> >

> >  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?

> 

> Like lots of people have already said, I've just added an extra field to "creator" however Martin's point is well made: authors are not normalised across records - meaning the same [identical] name is listed for each record it appears in.

> 

> This is, perhaps, something to feed into the EPrints 3.4 or 4.0 roadmap?

> 

> --

> 

> Ian Stuart.

> Developer: ORI, RJ-Broker, and OpenDepot.org Bibliographics and Multimedia Service Delivery team, EDINA, The University of Edinburgh.

> 

> 

> This email was sent via the University of Edinburgh.

> 

> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

> 

> *** Options:

> *** EPrints community wiki: http://wiki.eprints.org/

> *** EPrints developers Forum: http://forum.eprints.org/

> _____________________________________________________________

> This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.

> 

> The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.

> 

> The University of Southern Queensland is a registered provider of education with the Australian Government.

> (CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 )

> 

> *** Options:

> *** EPrints community wiki: http://wiki.eprints.org/

> *** EPrints developers Forum: http://forum.eprints.org/

 

 

*** EPrints community wiki: http://wiki.eprints.org/

*** EPrints developers Forum: http://forum.eprints.org/

_____________________________________________________________
This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.
 
The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.
 
The University of Southern Queensland is a registered provider of education with the Australian Government.
(CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 )

<USQ_AuthorID_Screenshots.pdf>*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/