Paul,
Not sure whether you meant ‘EPrints is commonly deployed’ or ‘the out-the-box configuration of EPrints that is commonly deployed’… I'm sure there's all sorts of weird and wonderful configurations for these things out there...
For a long time, we’ve had the following compound field, allowing for funder+grant (repeatable):
{
name => 'funder_grant',
type => 'compound',
fields => [
{
sub_name => 'funding_body',
type => 'text',
input_boxes => 1,
},
{
sub_name => 'grant_number',
type => 'text',
allow_null => 1,
}
],
multiple => 1,
input_boxes => 1,
},
(Ian, hope this hasn't caused you any problems, and won't cause us any problems with RJB!)
Our issue now is that humans don’t enter things into our repository – it’s all done through Symplectic and PURE – but we’re working on making sure the integration of this data is done the right way.
In days gone by, adding a field to EPrints was not for the faint-hearted, but now it's easy.
Maybe we need to look at the vanilla EPrints repository config and suggest some changes? (anyone have any idea how many new EPrints repositories are made each year?)
Cheers,
John
-----Original Message-----
From: Repositories discussion list [mailto:[log in to unmask]] On Behalf Of Ian Stuart
Sent: 24 March 2014 07:05
To: [log in to unmask]
Subject: Re: Was DC OAI-PMH, Now Funder/Project codes
Les,
Its implementation & management.
Eprints certainly implements fields for funders and codes.... which it
stores as a semi-colon separated string.
DSpace, on the other hand, appears not to have such a field (though one
could argue that one of the lesser-used Qualified-DC fields could be
shanghied into that role.)
Adding in option 3 is, as you say, not difficult - but requires more
change to the base repository that Paul was aiming for (ie, one needs to
add a new compound field to the database...)
Given the idea is to create a platform-neutral data-format, one needs
both EPrints and DSpace to support it (given they hold over 50% of the
global market between them.)
As an aside - I faced the same problem when I was constructing the data
packaging for The Broker. I had already gone for option 3 when RIOXX was
creating their guidelines.
In my case, I decided that it was a problem for the Individual
Repositories to recognise, and map, the funder & project identifiers
into a format that was used by their datasets.
To me, providing the correct relationship was more important, and the
IRs could catch-up as/when they could.
On 22/03/14 14:36, Leslie Carr wrote:
> You're going to have to help me out here. EPrints has certainly
> supported Option1 (separate fields for funder and projects) since
> 2007 and could easily accommodate option 3 (multivalue fields for
> each). If there's any problem with option 3 it is that it would stomp
> all over the repositories that already implement option 1.
>
> What am I missing here?
--
Ian Stuart.
Developer: ORI, RJ-Broker, and OpenDepot.org
Bibliographics and Multimedia Service Delivery team,
EDINA,
The University of Edinburgh.
http://edina.ac.uk/
This email was sent via the University of Edinburgh.
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
