Just one comment from my side, as I have been leading the CERIF TG for
several years. If you refer to CERIF++ with respect to vocabularies
(semantics) - then yes, if you refer to the syntax, then no, I would
say. Also, you have to clearly distinguish if you talk about CERIF
relational or CERIF XML. They are two very different things and serve
very different purposes.
I was not able to follow the discussion in details, I am afraid. What is
the goal of this discussion? What are the requirements that have to be
met? In my view then the discussion could be much more focused as it is now.
All the Best,
Dr Brigitte Joerg
Board Member eurocris.org
Co-Chair Data in Context IG rd-alliance.org
CERIF TG Leader (2004-2012) eurocris.org
mail: [log in to unmask]
On 24/03/2014 12:22, Leslie Carr 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)?
> On 24 Mar 2014, at 10:05, John Salter <[log in to unmask]> wrote:
>> 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?)
>> -----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
>> 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,
>> 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.