Now’s a good time to talk about what the default schema looks like for EPrints 4.
Should it be the union of every stakeholder’s interests (CERIF++) or should it be really cut back to bare bones to allow repository administrators to roll their own?
Should it be easily updateable over-the-air in a modular fashion to allow Yet Another Research Council Initiative/Mandate to be accommodated (rather like iOS upgrades)?
—
Les
On 24 Mar 2014, at 10:05, John Salter <[log in to unmask]> wrote:
> 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.
|