> I would think, at this point, a fairly bare-boned approach, with a selection of templates for the more common use-cases, to get people started?
Yes - my thoughts exactly!
[user@server]>bin/epadmin create
... Please select an ID...
>myLovelyNewRepositoy
... what type or repository would you like? [publications|research-data|rich-media|oer|mixed]
> how much can be achieved ... with minimal schema
I'd suggest quite a bit - based on recent-ish discussions with Seb :o)
I think that in Leeds we have at least 3 different flavours of repository:
White Rose Research Online / ETheses Online: 'normal' publication/thesis-centric content
Digital Library: http://digital.library.leeds.ac.uk/ - digitised content from our 'Special Collections' - fed from a Museum/Gallery/Archive Collection management system
Research Data: [I'll let you guess what's in that one].
- all have their own needs - metadata requirements; interfaces with other systems; harvest formats;
The plugin architecture within EPrints allows out-the-box that works, and also 'I need to customise blah *and must remember to customise the export format to match*' (although I'm not entirely confident that the second part of that always happens).
So, EPrints4... who's in?!
Maybe we should try to crowdsource what customisations have already been made to EPrints repositories and see where the overlaps are?
Cheers,
John
-----Original Message-----
From: Repositories discussion list [mailto:[log in to unmask]] On Behalf Of Paul Walk
Sent: 24 March 2014 12:53
To: [log in to unmask]
Subject: Re: Was DC OAI-PMH, Now Funder/Project codes
I would think, at this point, a fairly bare-boned approach, with a selection of templates for the more common use-cases, to get people started?
While I accept that a schema of some description is likely to be necessary, I wonder how much can be achieved (in terms of usable user-interfaces and internal logic) with minimal schema?
The idea of supporting the giant, and growing set of all requirements from one schema, seems unsustainable, and the notion of CERIF++ caused me to have to go and have a little cry...
Paul
On 24 Mar 2014, at 12:22, Leslie Carr <[log in to unmask]> wrote:
> 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.
-------------------------------------------
Paul Walk
http://www.paulwalk.net
-------------------------------------------
