News from 2015

First RCUK-compliant record!

I'm pleased to report that we have seen our first RCUK-compliant RIOXX record in the wild. Well done to the University of Keele Research Repository!

You can see the validation report, and the record itself.


Currently, all of those institutional repositories which have declared support for RIOXX are based on the ePrints software, using a plugin especially developed to support RIOXX. There is a little (although not much) information about this plugin here - Jisc paid for the work, but it is not clear from that page who actually did the development (although there is a useful list of potential sources of technical support).

A manager of one of these repositories recently contacted me to suggest that the validation and reporting script (output here) was offering a distorted view of the adoptions and accuracy or RIOXX reporting because it was harvesting a sample of the first 10 records, rather than harvesting more recently created or updated records which had more chance of being RIOXX-compatible.

There is a reason why this should not actually make any difference - and I'll come on to that in a moment- but in the meantime, we have re-run the script, configuring the OAI-PMH request to only ask for records with a date-stamp since 2015-01-01 (as well as a metadata-format of 'rioxx'). Formally, the OAI-PMH request therefore becomes:


where {BASE-URL} is the base URL of a given repository.

The results of this are somewhat different to the results from previously, where we did not specify any date-stamp. What this suggests is that the OAI-PMH request which ought to work:


is actually returning records which the repository managers might not wish it to be returning - that is to say records which are not actually ready to be declared as 'RIOXX-compatible'. The OAI-PMH standard states that:

Records should be included only for items from which the metadata format matching the metadataPrefix can be disseminated.

I have no idea if this is a fault in the ePrints plugin, or if it is more to do with the way in which it has been configured. It ought to be something which can be fixed though, so I wonder if any repository managers - particularly those who have implemented the ePrints plugin - have any views on this? Now that there has been some time to work with this plugin, there may be emerging good practice in terms of its configuration and deployment worth sharing with peers.

It may be that we can improve on those compliance rates by simply filtering what are being disseminated as 'RIOXX-compatible' records.

In the spirit of open collaboration, please feel free to leave comments below!

RIOXX now supported by 30 institutional repositories

I'm very pleased to note that the number of instituional repositories declaring support for RIOXX has reached 30! This number has trebled in 6 months which is a healthy rate of adoption.

This is due to the growing adoption of the Jisc-funded ePrints plugin. It would be good to see some other systems listed: there are, I believe, ongoing developments to introduce RIOXX support into other repository systems.

Who will be next? Will it be DSpace? Will it be Hydra? Watch this space....

Compatibility with OpenAIRE

RIOXX operates in a similar space to OpenAIRE and so the RIOXX team at EDINA have been concerned to make the two metadata application profiles as mutually compatible as possible.

Working closely with the OpenAIRE team, we have prepared a document which explains how to 'map' properties from RIOXX 2.0 to OpenAIRE 3.0, with some guidance also on mapping terms in some of the controlled vocabularies.

This 'crosswalk' document can be found here.

We hope this is useful.

HHuLOA review of RIOXX

The universities of Hull, Huddersfield and Lincoln, collaborating as HHuLOA, have been analysing RIOXX 2.0 in the context of implementation within their various repository systems. While Lincoln and Huddersfield have deployed ePrints, Hull has a Hydra repository. This is the first information I have seen from people intending to implement RIOXX in a Hydra system, so is very welcome!

You can read a summary of their findings, or access the full report (PDF)

On validation

Following a very useful discussion with Mike Taylor (see comments on this post), I have split the validation of RIOXX records into two stages:

  1. a basic syntax check, following less strict rules and constraints than the full RCUK requirements
  2. a strict validation check against the full RCUK requirements

The reason for doing this is to allow implementers to check that their software is correctly set-up. For example, if a RIOXX-enabling plugin for a repository is correctly configured, but the repository's metadata holds values for the 'version' which are not from the RCUK-approved vocabulary for versions, then records from that repository will fail the full RCUK validation test. However, it will be useful for repository managers to have some reassurance that at least their repository software, and any RIOXX plugin, are functioning correctly. Hence the second, basic RIOXX validation.

This approach opens up the possibility of further, separate, profiles of RIOXX for other business cases, where the RIOXX syntax (and consequently repository system plugins) need not change.

View results of testing samples from several repositories for conformance to the two profiles.

Kudos to the 'Enlighten' repository at Glasgow University for being the first repository tested to have passed the basic RIOXX validation test!

I hope this is not confusing - it is intended to help.

Comments welcome!

RIOXX records in the wild

I am periodically surveying repositories, using a list generated by the OpenDOAR API, to see which of these are serving RIOXX 2.0 metadata records. At the time of writing, 11 repositories are declaring support for this metadata format.

You can see these listed here.

I think that these early adopters are all ePrints systems, using the recently developed ePrints plugin for RIOXX.

For each repository, I have harvested 10 RIOXX records to examine them for compliance with the RIOXX metadata profile. The results of this check are linked to from the row for each repository.

So far, none of the records harvested are compliant. This is to be expected, as testing and fixing continues with the ePrints plugin, and as the workflows within the repositories are adjusted to accomodate the new information requirements.

I hope that the repository 'validation reports' offer some useful indicators and help repository managers to achieve compliance.

RIOXX 2.0 final release

The RIOXX team is pleased to announce the release of version 2.0 of the RIOXX metadata application profile and guidelines.

The following resources are now available:

The team would like to acknowledge the significant support in particular of Ben Ryan (RCUK) and Ben Johnson (HEFCE) in preparing this version 2.0 release, and would also like to thank the many contributors who have offered reviews, suggestions and corrections over the last few months. RIOXX 2.0 is a significantly improved metadata application profile thanks to the level and quality of input we have received from the community.

We would also like to thank Jisc for having provided funding and support for the crucial early stages in the development of the RIOXX application profile.

more posts (archive)