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