> ## Response to comments on the application profile (v0.91) ### dc:creator
> * we are not using dc:creator, having established rioxxterms:creator for this purpose. ID is a valid attribute in rioxxterms:creator

Just a quick follow-up to my previous comment...

I think it is somewhat dangerous to adopt an approach which says we need to define a new property simply because we want to add a new attribute to that property in one particular encoding (in this case XML). Such an approach is particularly problematic in an encoding environment that lacks any method of carrying assertions about property semantics other than by convention (as is the case with XML).

(Note: if you were defining rioxxterms:creator to have different semantics from dc:creator then defining a new property would be OK... but I don't think you are doing that?).

How dangerous?

Well, that's difficult to say, but my gut feeling is that choosing rioxxterms:creator rather than dc:creator will fragment this application away from other DC-based applications with an overall loss of interoperability. (But I accept that it is hard to estimate how serious the consequences of that will be).

Andy Powell
Head of Product Research

Eduserv

[log in to unmask] | 01225 474 319 | 07989 476 710
www.eduserv.org.uk | http://www.twitter.com/andypowe11 | http://blog.eduserv.org.uk | http://www.linkedin.com/company/eduserv

Eduserv is a company limited by guarantee (registered in England & Wales, company number: 3763109) and a charity (charity number 1079456), whose registered office is at Royal Mead, Railway Place, Bath, BA1 1SR.
-----Original Message-----
From: Repositories discussion list [mailto:[log in to unmask]] On Behalf Of Paul Walk
Sent: 08 April 2013 16:52
To: [log in to unmask]
Subject: Re: Comments on RIOXX 0.91 from OpenAIRE and COAR

Dear Najla,
many thanks for taking the time to offer this detailed feedback on behalf of COAR and OpenAIRE. We have, of course, consulted with both during our development of the RIOXX Guidelines.

I offer a response to the specific details of your feedback below, but in general I would like to say that we have been careful to develop RIOXX in respect of three guiding principles:

* it must satisfy the RCUK requirements
* it should be simple to implement for as many Institutional Repositories (IRs) as possible
* it should do nothing to impede the deployment of other initiatives in this space - with a particular focus on OpenAIRE and EThOS

I would also like to make clear that we consider RIOXX, in its current form at least, to be an interim solution. In the medium term we anticipate such information being formatted according to the CERIF standard.

I hope that this response is helpful. I am of course happy to answer further questions, however you should be aware that we must release a final version very soon, and that development of supporting software has already begun, so we will be unlikely to make major changes now.

Regards,

Paul (on behalf of the RIOXX team)
-------------------------------------------
Paul Walk
Blog: http://blog.paulwalk.net
Skype: paulwalk
Twitter: paulwalk
Mobile: 07812 510001
-------------------------------------------





# Response to specific points

## On the general point regarding the UK developing a set of UK-specific guidelines We have conducted a very careful process of consultation, both within the UK and with other European parties, to determine the best approach to satisfying the requirements set by RCUK. Our starting point was to consider the OpenAIRE Guidelines as a candidate approach. If we had been able to use the OpenAIRE Guidelines then we would certainly have done so - the introduction of a new set of guidelines and a new application profile (+software development) comes at a cost. However, we were unable to adopt the OpenAIRE Guidelines as they stood: some of the reasons for this are detailed below.

## How will the metadata will be exposed (OAI-PMH metadata scheme and prefix)?
We have commissioned work to implement plugins/patches for ePrints and DSpace which are the market-leaders in terms of institutional repository deployments in the UK. As part of this development work, the finer details of implementation of the RIOXX application profile are being worked out, tested and validated. This work should be completed imminently, and we will then publish detailed guidelines about how to properly expose the metadata via OAI-PMH.

## Why have existing controlled vocabularies (e.g. http://purl.org/REP/standards/info-eu-repo) not been considered?
RIOXX is waiting for the outputs of the Vocabularies for Open Access (V4OA) project which is seeking consensus across *all* stakeholders in the open access space. We have intentionally avoided mandating particular vocabularies where possible so that we do  not prejudice this important work.

## Response to comments on the application profile (v0.91) ### dc:creator
* we are not using dc:creator, having established rioxxterms:creator for this purpose. ID is a valid attribute in rioxxterms:creator
* the guidelines state "Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically" which would seem to address your concern about addressing type or scheme - however we will consider how we could be more explicit about this aspect
* regarding how to encode other identifier authority types - that is not our concern - we simply require that they be recognisable and actionable
* ORCID is recommended following an exhaustive study and consultation carried out by the Jisc over the last year. You will note that ORCID is *recommended*, not mandated
* regarding the disambiguation between people, organisations and services: our concern is to capture actionable identifiers - what is inferred from them is not directly a RIOXX concern

### dc:identifier
It is a requirement that institutional repositories indicate reliably how they have complied with the open access requirements from RCUK. This will involve harvesting and aggregating RIOXX records and being able to reliably ascertain that an open access output has been made available. The consensus from those involved in harvesting metadata records from IRs is that a reliable link to an output is essential. Different practices, software implementations and previous guidelines have created a varied situation in this respect - it is for this reasons that the RIOXX guidelines are not stricter still regarding this element.

### dc:source
The Driver Guidelines give an example using an ISSN - which is what we *recommend*.

### dc:title
Our intention is to simplify in favour of the common case. Is there a compelling reason not to make this simple?

### rioxxterms:funder
This is simply a matter of judgement. While it is a matter of much debate, the use of the 'dotted' qualifying syntax is not universally recommended. In any case, we are adding a new piece of information to the standard output from IRs - it is entirely reasonable to define it separately. This approach was partly informed by the approach taken in [EThOS](http://ethostoolkit.cranfield.ac.uk/tiki-index.php?page_ref_id=69)

### rioxxterms:projectid
See response above for rioxxterms:funder. Also, the semantics for terms such as 'grant' and 'project' are complex - there is a lot of scope for ambiguity. It was strongly recommended to us by RCUK that we use the term 'project ID' rather than, for example, 'grant number'
Regarding the OpenAIRE approach (info:eu-repo/grantAgreement/): Our starting point was a desire to use this approach. However, it became apparent that the syntax used in the OpenAIRE approach, which gives semantic significance to the '/' character, would be problematic for project IDs issued by UK Research Councils which use that character to carry different semantics. It was suggested that we could solve this through insisting that repositories URLEncode this value in their output, but this was rejected for two reasons:

* it does not comply with our design principle of minimum burden on IRs
* we are advised that URLEncoding leads to more errors as it is often poorly implemented

A second issue with the OpenAIRE approach is its reliance on the 'info' URI scheme. This scheme is effectively deprecated - see the scheme's [home page](http://info-uri.info)

### General remarks on funder and projectid Please see [a detailed blog post on this aspect, explaining the rationale behind the choice of approach](http://rioxx.net/2013/01/29/approaches-to-handling-funders-and-projectids-in-a-rioxx-record/)

* there is no available lookup service for projectIDs (yet)
* there is a *prototype* lookup service for funder names available - this is being tested by the developers who are building plugins/patches for ePrints & DSpace.

### dc:format
(See response above for dc:identifier)

### dc:publisher
We will consider your suggestion that more guidance be offered here - thanks.

### dc:rights
This aspect is a pressing issue for the previously mentioned V4OA project - we are obliged to wait for the consensus which it is hoped will emerge from that process. We anticipate, from the RCUK policy, that the common case will be the use of a CC license as we indicate in the application profile. We have deliberately avoided further recommendations for the reasons given.

### dc:contributor
This is not used - we have introduced rioxxterms:contributor instead. Please see the response earlier in this post to the points made about dc:creator/rioxxterms:creator

### dc:subject
Regarding "current practice for using controlled vocabularies introduced in DRIVER Guidelines v2": It is not apparent to us that this is current practice in most IRs. Nonetheless, we have been careful to recommend an approach which is compatible with OpenAIRE/Driver 2.

### dc:type
This is another example of a requirement for a vocabulary where we must await the outcomes of the V4OA process. There are some very compelling alternatives to the vocabularies indicated in Driver, such as the vocabularies already used in the UK Research Councils' systems.

### dcterms:reference
We will certainly look at the new guidelines being prepared in OpenAIRE Guidelines v3, but it may now be too late for these to impact on this phase of RIOXX



Many thanks for again for your detailed feedback.

Regards,

Paul
On 8 Apr 2013, at 08:38, "Rettberg, Najla" <[log in to unmask]> wrote:

> Dear RIOXX team,
> On behalf of both COAR and OpenAIRE, we'd like to thank you for the chance to openly comment on your draft guidelines, RIOXX (updated version 0.91). Both  of  our initiatives, representing international communities of OA repositories, welcome steps that contribute to their overall interoperability. Indeed, working together to align our strategies is key to international repository harmonisation. We have a few comments we'd like to share with you below, but we'd also like to take this opportunity for future collaboration with you.
> While community-specific guidelines might better serve local needs, from a European/international perspective it is not entirely clear of the rationale to develop a set of national-level guidelines. The international repository community have worked on defining a set of widely accepted guidelines, namely the DRIVER and OpenAIRE guidelines. This might well lead to a situation whereby non-UK repositories have to be compliant to yet another set of guidelines, if they want to interoperate with the UK. Reversely,  UK repositories will still have to be also compliant with DRIVER and OpenAIRE+ guidelines  if they want to integrate with the international repositories infrastructure.
> Give that any valuable service built on top of the repositories infrastructure is to have a global scope to be truly useful, it might perhaps have been more useful to the international community of repositories if these new guidelines had been approached more as a contribution, or an enhancement, to improve the already existing guidelines, on the basis of international consensus and collaboration.  We'd welcome your view on this. And we hope there might be scope to align further on the forthcoming OpenAIRE set of new Guidelines for Data Repository Managers 1.0 and Guidelines for CRIS Managers (in review phase).
> More detailed Feedback from OpenAIRE on the UK Metadata Guidelines for Open Access Repositories:
>  
> Although the document is well structured and written, the following is 
> not clear to the reader
> * how the metadata will be exposed (OAI-PMH metadata scheme and 
> prefix)
> * why existing controlled vocabularies (e.g. 
> http://purl.org/REP/standards/info-eu-repo) are not considered. For the table of elements see remarks on the application profile below. 
>  
> Feedback on the application profile:
> ==
> dc:creator
> -> Attribute "id" is not valid in Dublin Core namespace
> (http://purl.org/dc/elements/1.1)
> -> semantics of id attribute are already defined: 
> http://www.w3.org/TR/xml-id/
> -> identifier for creator-entities should at least express type or
> scheme and identifier
> -> ORCID is not the only author identifier authority, how to encode
> other author identifiers if applicable?
> -> why is ORCID recommended, others not?
> -> how to disambiguate between identifiers for persons, organizations
> and services ?
>  
> dc:identifier
> -> cardinality set to one conflicts with existing practices to express
> other kinds of identifiers related to the described resource
> -> it conflicts with the DRIVER v2 and OpenAIRE Guidelines:
> "However, there must be at least one actionable identifier that points 
> to the jump-off page with the full text document or directly to the 
> full text document. In case of more than one actionable identifier, 
> the service provider will use, by default, the first actionable 
> identifier in the list to direct the end-user to."
> -> a fulltext document might be split to multiple resources (e.g. 
> Enhanced Publication)
>  
> dc:language
> -> ok
>  
> dc:source
> -> conflicts with recommended practices in other guidelines, e.g. DRIVER v2:
> "For publications use the DC:SOURCE field for inserting information a 
> person can use to appropriately make a citation of the record he/she 
> has found. Preferably use the APA style of writing references."
>  
> dc:title
> -> cardinality set to one conflicts with recommendations in other
> guidelines, e.g. DRIVER v2:
> "If necessary, repeat this character for multiple titles."
>  
> dcterms:issued
> -> ok, similar to recommendations for dc:date in DRIVER v2 guidelines
>  
> rioxxterms:funder
> -> it is not clear why a new element name is introduced while 
> -> qualifiers
> for Dublin Core exist to express the same meaning: 
> dc:contributor.role="funder"
>  
> rioxxterms:projectid
> -> it is not clear why a new element is introduced while qualifiers 
> -> for
> Dublin Core exist to express the same meaning: 
> dc:identifier.grantnumber
>  
> general remarks on funder and projectid ===
> -> a project is funded by a funder and assigned a grant agreement
> identifier or project identifier, meaning that this is a complex 
> field, that should be expressed either together in a single field 
> (similar to the OpenAIRE guidelines) or hierarchically.
> -> otherwise the separated values are ambiguous referencing a lookup 
> -> service or controlled vocabulary for funder and
> project-id is missing
>  
> rioxxterms:projectid
> -> it is not clear why a new element is introduced instead of using 
> -> the OpenAIRE approach (namespace info:eu-repo/grantAgreement/ on 
> -> dc:relation) or even through  existing qualifiers for Dublin Core 
> -> to express the same meaning: dc:identifier.grantnumber
>  
>  
> dc:description
> -> ok
>  
> dc:format
> -> see comment on dc:identifier
>  
> dc:publisher
> -> more usage instruction needed, e.g. relation publisher vs. creator 
> -> of
> the resource, see Driver Guidelines v2
>  
> dc:rights
> -> deviates from recommended practice in the OpenAIRE guidelines to
> express two things:
>    1) the license condition (creative commons etc.)
>    2) the access level of the resource by a controlled vocabulary as 
> introduced in the OpenAIRE guidelines (openAccess, closedAccess,
> embargoedAccess)
>    2a) in case of embargoedAccess an element describing the end of the 
> embargo period is missin in the RIOXX application profile
> -> cardinality set to one conflicts when expressing license and access
> conditions
>  
> dc:contributor
> -> see comments on dc:creator
>  
> dc:subject
> -> please consider current practice for using controlled vocabularies
> introduced in DRIVER Guidelines v2
>  
> dc:type
> -> please consider current practice for using controlled vocabularies
> introduced in DRIVER Guidelines v2
>  
> dc:relation
> -> recommendation not clear
>  
> dcterms:reference
> -> ambiguity regarding the type of the referenced resource; compare 
> -> with
> OpenAIRE Guidelines v3
>  
>  
>  
>  
>  
>  
>  
>  
>  
> *******
> Najla Rettberg
> Göttingen State and University Library
> 49 (0)551- 39 5242
> [log in to unmask]
> www.openaire.eu
>  
>