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