RIOXX review and proposed practice

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.


4 thoughts on “RIOXX review and proposed practice”

  1. Thanks for publishing your findings on this. One question. You say “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”. But don’t the fairly detailed explanations in the NISO recommendation give you the precision you need for this?

    1. Mike,

      Thanks for the feedback. I agree that the definitions of the different versions as laid out by NISO are clear and precise. The dilemma is in how these are put into practice. Until publishers adopt these definitions (i.e., define which of their versions fall into each category) and are clear in their own communications about which are which it is difficult for repositories to record without an element of guesswork coming into play. There is too much uncertainty amongst repository staff and publishers at the moment how versions of documents from publishers fit into policy requirements, given different publisher workflows. The dilemma in the context of HEFCE and RIOXX is that repositories cannot at the moment guarantee to be able to know which version is being held according to the defined list. If the NISO list is adopted widely then there is a solution: what the timeline is for this remains to be seen.


      1. Thanks, Chris, that makes sense. So you feel that you need better article-level metadata from publishers in order to populate this field meaningfully? Or would a one-off statement from each publisher suffice? “The manuscripts that we provide should be considered of type ‘AM'” or similar?

        In the mean time, for those of us who want to consume your metadata, it would be very helpful if you were able at least to make a lower-bound guess on how close to the VoR your versions are, instead of just throwing in the towel and saying “unknown”. For example, even if you’re unable to distinguish between VoR, CVoR and EVoR, it’s surely better to code “VoR” than nothing?

        P.S. I wish your blog’s commenting system had a “notify be about followup comments” checkbox.

        1. Ideally, better article-level metadata would be good. But a statement from publishers on what version they are willing to provide for repository use would be a good first step.

          I take your point about having something rather than nothing and will look at what we might be able to do without misrepresenting anything.


Comments are closed.