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?
Developer: ORI, RJ-Broker, and OpenDepot.org
Bibliographics and Multimedia Service Delivery team,
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.