One of the HHuLOA project’s workpackages is to carry out technical work to ensure that the repositories at the partner institutions are fit for purpose in capturing the information we need to ensure compliance with the HEFCE REF Open Access Policy. Paragraph 38 in the HEFCE Open Access FAQ states:
“The RIOXX profile is designed primarily to fulfil Research Councils UK’s requirements for metadata collection and reporting on open access. It is compatible with the information and audit requirements for the open-access policy in the next REF, which also overlap with RIOXX. The REF information requirements document shows all areas where overlaps exist between RIOXX and REF.”
The information requirements document outlines how the RIOXX profile can capture relevant information, acknowledging the additional information that will be required as well (mainly around the reporting of exceptions). As it is anticipated that the detail of HEFCE’s requirements aside of RIOXX will be developed further, HHuLOA decided that we would start by examining the RIOXX profile and understanding how this would work in our repository systems. The output from this is the attached analysis of the RIOXX elements, with proposed practice on applying these and capturing the information for them. We can’t say that the guidance will necessarily apply across all repositories, but we hope that by sharing it we will help those working with RIOXX. Feedback is very welcome.
Most of the elements generated some queries, even if minor, and we are going away to understand better what the implications of these are. Two of the mandatory elements, though, resulted in more discussion than others:
ali:licence_ref – this element is intended to hold information about licences under which the open access article is held, to make it clear under which permissions it can be used. Where a Creative Commons or equivalent licence is being applied it is clear how this can be used. However, it is less clear in the context of publisher licences, as the presentation of this information is not yet standardised or, in some cases, persistent. The RIOXX standard provides a back-up approach by using URLs that refer to ‘all rights reserved’ statements generically, and we will most likely default to these until publisher information is more readily available. This element is taken from NISO, and they do indicate they see this as being an ongoing development. We would urge publishers to heed this call and make licence information available through persistent URLs akin to CC licence link availability.
rioxxterms:version – this element is intended to hold an entry from a fixed category list defining the version of the file available through the repository. Whilst having a fixed list clearly has value in helping to structure this information, it is very unclear what versions from publishers fall into which category: most institutions struggle with acquiring an AAM, never mind understanding which type of AAM it is. It is not clear that the category list is understood or being used by publishers. Hence, defaulting to NA for not applicable or unknown (or making a best guess) will be necessary, at least initially. Further definition and common application of the category types is essential if this information is to be collected properly and be of value.
—————————-
As a project we will be taking forward our review of RIOXX into our system developments, following three distinct paths:
Hull – RIOXX will be implemented alongside other REF-related fields within our Hydra repository. We will also be exploring how we can best share this work with other Hydra adopters in the UK.
Lincoln – RIOXX is being implemented within a locally-hosted version of EPrints, making changes in liaison with the EPrints team in Southampton.
Huddersfield – RIOXX is being implemented as part of a system upgrade to the EPrints-hosted repository, using the RIOXX plugin.
We will endeavour to report on our ongoing experiences in making use of RIOXX as we go along.