Hacking RIOXX


On the surface, adopting the RIOXX metadata profile seems like a trivial challenge. The new UK metadata standard only has a few mandatory fields of which some can even be directly mapped from the DSpace schema. Here is what Atmire and UK DSpace institutions have learned in the process of adopting RIOXX.

The overarching challenge with the adoption of RIOXX is to add as little extra complexity and ambiguity to the DSpace submission interface. This is particularly challenging as some fields are very similar to fields already present in DSpace, but still have important differences.

Date granularity

Traditionally, date fields that are qualified as mandatory in the DSpace submission forms can be completed with a year, allowing the user to leave month and day empty. This is problematic for declaring dates of acceptance and license start dates in RIOXX, as they require the day and month to be specified.

Hack #1: Make sure your submission forms make month and day required or inform the user that missing months or days will be filled out with a default value in the crosswalk.

Item types

The controlled vocabulary of acceptable rioxxterms types is quite extensive:

  • Book
  • Book chapter
  • Book edited
  • Conference Paper/Proceeding/Abstract
  • Journal Article/Review
  • Manual/Guide
  • Monograph
  • Policy briefing report
  • Technical Report
  • Technical Standard
  • Thesis
  • Other
  • Consultancy Report
  • Working paper

Just because these types are acceptable, does not mean that repository managers should aim for RIOXX compliance on all of these types. In fact, the two types in bold are really the key types that are currently relevant for RCUK and REF 2020 compliance. Knowing that date of acceptance, funder and project ID are mandatory for RIOXX compliance, one can even wonder what date of acceptance even means for a work that is not published with an external publisher.

Hack #2: The most elegant solution, but also the most time-intensive one to develop, is to make use of the DSpace type-based submission system. Using this system, you can have different submission form configurations for different item types. If you prefer the simplicity of having a single submission form configuration for all item types, it is advised to make RIOXX fields like date of acceptance optional, as users won't be able to complete them for specific item types.


Similar to the vocabulary for item types, the vocabulary for versions of the full text also has quite a few values:

  • AO = Author's Original
  • SMUR = Submitted Manuscript Under Review
  • AM = Accepted Manuscript
  • P = Proof
  • VoR = Version of Record
  • CVoR = Corrected Version of Record
  • EVoR = Enhanced Version of Record
  • NA = Not Applicable (or Unknown)

Not everyone is already accustomed to these terms from the Journal Article Versions (JAV): Recommendations of the NISO/ALPSP JAV Technical Working Group. Publishers are also not always clearly mapping their own descriptions of the full text version to this vocabulary. Therefore, it is advised to keep the list restricted to those values you actually want to use and explain to your submitters and staff.

Hack #3: Carefully select a subset of the vocabulary for your submission forms and think about which of these versions you want to have as default selected in the dropdown. Keep in mind that only AM, P, VoR, CVoR and EVoR are acceptable versions for REF compliance.

Funder and Project ID

A valid RIOXX record requires at least one project/grant identifier associated with a funder. In the DSpace RIOXX patch, this is implemented as a mandatory submission step. In this step, the user can fill out a project ID and associate it with a funder from FundRef. This has lead to the issue where submitters were not able to complete their submissions, if their work did not have a formal source of funding, or if their funder was not listed in FundRef.

Institutions are currently using different strategies to deal with this. One way to ensure there a funder and project id get included in every submission, is to add a default one if they user doesn't specify one themselves. More often than not, the institution running the repository itself is listed as a funder in FundRef. So a sensible default becomes the project ID values "Unspecified", associated with the FundRef id of the institution running the repository.

Other institutions prefer to make the project/funder lookup step optional, knowing that the resulting submissions won't be exposed in the RIOXX crosswalk if a funder/project ID pair is missing.

Hack #4: Adopt the latest version of the RIOXX patch once it comes out, as it will have the functionality to make the funder/project lookup step optional and to specify a "Default Funder".

Need help?

Atmire operates a dedicated RIOXX DSpace support desk. Contact us to request an account.