Rioxx v3.0 Release Published

The Rioxx Governance Group (RGG) is pleased to announce that the final release of 'Rioxx: The Research Outputs Metadata Schema' version 3.0 has now been published.

The publication of version 3.0 concludes over 3 years of activity, including extensive community consultation, as well as the publication of several candidate releases to solicit further comment from the community. Thanks to all those who contributed!

The general direction of travel for Rioxx 3.0 has been well advertised in previous blog post. More than anything this direction has entailed the process of further optimizing Rioxx for discovery. The RGG has therefore paid particular attention to Rioxx in harvesting and aggregation, and its ability to better reflect the relational nature of scholarly works. Those familiar with version 2.0 will therefore notice some significant changes to Rioxx, the most notable of which include:

• The introduction of new properties <rioxxterms:grant> and <rioxxterms:project>, to better distinguish between funded research work and ongoing (potentially unfunded) research projects.
• Improved identification of creators and contributors through the introduction of <rioxxterms:name> and <rioxxterms:id>, to be used as sub-properties <rioxxterms:creator> and <rioxxterms:contributor>.
• Superior modelling of significant dates in the publication and repository deposit lifecyle, including the creation of <rioxxterms:record_public_release_date> and attributes within <dc:relation> and <rioxxterms:ext_relation> to capture deposit and exposure dates.
• A major change to the use of <dc:identifier>, which now communicates an HTTP(S) URI identifying the primary resource, and which resolves to a repository landing page. ## The future is relational Perhaps the biggest change between versions 2.0 and 3.0 includes the use of <dc:identifier>, which has changed -- as noted above. But version 3.0 also introduces changes to the use of <dc:relation>, and the introduction of a new, addition relational property: <rioxxterms:ext_relation>.

It is necessary to accept that the future of scholarly outputs is now highly relational. Scholarly outputs may evolve via several significant iterations. They also increasingly demonstrate a graph of related objects, some of which may be essential to interpreting and/or describing the scholarly output itself. Rioxx 3.0 therefore introduces the notion of custodianship to assist users and machines in interpreting these relations.

Custodianship within Rioxx refers to the concept that the location of a resource is significant to understanding the nature of the thing being described by the Rioxx record. It is also highly relevant to those machines seeking to process, harvest, or aggregate Rioxx metadata. Resources under direct custodianship of a repository are therefore those which are under direct management of a local repository or publication platform. These are resources that the local system controls and maintains. Resources outside this direct custodianship (e.g. resources at or hosted by third party services) demonstrate external custodianship, and form a wider scholarly graph around the primary resource being described by the Rioxx record. <dc:relation> and <rioxxterms:ext_relation> help us in modelling these relations.

The following now applies in Rioxx version 3.0:

• <dc:relation> is now the principal property for expressing the existence of harvestable file content, as well as other internally curated resources. <dc:relation> is therefore used to declare resources under direct custodianship of the local repository. This property is supplemented by a series of attributes, all of which help to describe the nature of the harvestable content.
• <rioxxterms:ext_relation> is used to convey external relations to related sources. Such relations will be scholarly resources hosted externally, i.e. outside of the direct custodianship of the repository asserting the relational associations. Examples of these associations might typically include alternative 'expressions' of what <dc:relation> is communicating (e.g. preprint, VoR, etc.) and/or resources relevant to understanding, or complementing, <dc:relation> such as related research data, software, code, instruments, and so forth.

An example of how <dc:relation> and <rioxxterms:ext_relation> might be used is provided in the Rioxx snippet below, and the conceptual diagram above should also help readers to distinguish between the two.

    <dc:relation
            rel="item"
            type="application/pdf"
            coar_version="https://purl.org/coar/version/c_ab4af688f83e57aa"
            coar_type="https://purl.org/coar/resource_type/c_6501"
            deposit_date="2010-01-20"
            resource_exposed_date="2020-01-20"
            access_rights="https://purl.org/coar/access_right/c_abf2"
            license_ref="https://creativecommons.org/licenses/by-nc-nd/4.0">
            https://spiral.imperial.ac.uk/bitstream/10044/1/76123/2/POP19-AR-58732_accepted.pdf
    </dc:relation>

    <dc:relation rel="cite-as">http://hdl.handle.net/10044/1/76123</dc:relation>
    
    <rioxxterms:ext_relation
            rel="cite-as"
            coar_type="http://purl.org/coar/resource_type/c_6501"
            coar_version="http://purl.org/coar/version/c_970fb48d4fbd8a8">
        https://doi.org/10.1063/1.5128830
    </rioxxterms:ext_relation>

A number of example Rioxx records are provided as an appendix to the version 3.0 schema documentation, each of which demonstrates a different repository use cases.

There is nothing permanent except change

This announcement of Rioxx version 3.0 necessarily highlights the more significant changes from version 2.0. But a full list of changes can be found in the [release notes](/release notes/). The RGG, as well as UKCORR, will work with the community, including developers and funders, to assist and promote take-up of Rioxx version 3.0 in repositories and beyond!

Rioxx continues to be actively maintained and developed. Though version 3.0 has been published the process of review never ends. An updated schema will be issued in future. Comments, issues, etc. are always invited through the Rioxx GitHub repository.

Harvesting Rioxx: optimising repositories for content aggregation

A previous blog post over the summer of 2022) reported that a v3.0 Release Candidate of Rioxx had been published. Publication of this candidate has stimulated additional feedback from the community and the Rioxx Governance Group (RGG) is therefore working hard to address this feedback, ahead of finalizing the publication of Rioxx v3.0.

In the meantime, members of the RGG recently presented at The 3rd Workshop on Open Citations and Open Scholarly Metadata 2022 (WOOC2022) about Rioxx: Enhancing discovery and enriching the scholarly graph with the Research Outputs Metadata Schema (Rioxx). This contribution highlighted recent Rioxx developments and how it had the potential to contribute to the burgeoning scholarly graph; but it also highlighted the importance of Rioxx as a facilitator of aggregation. That is, how Rioxx can better support the operations of content harvesters which are seeking to aggregate repository content.

Aggregation services harvest content from thousands of repositories across the world, improving its discovery and enhancing its potential re-use. They also generate a rich data platform for delivering advanced text and data mining (TDM) features, capable of unlocking new knowledge and scientific discoveries. The CORE API, OpenAIRE Discover portfolio and BASE represent obvious examples. But the growth of aggregated data also enables innovation and tangible benefits of the 'network effect', such as the CORE Recommender and CORE Discovery.

Improving the efficacy of aggregation is therefore important. We have previously reported on how Rioxx supports aggregation efficacy by expressing repository metadata in a more harvester friendly way. The RGG mission continues to focus on this, and the summer 2022 release candidate is a contribution to making Rioxx even better for aggregators. Because aggregation is a key component of the scholarly repository concept: that thousands of open repositories can operate an indenpdent, distributed service model but simultaneously contribute to the scholarly commons.

The value of aggregators, which provide data tools for TDM and the creation of new services, is already upon us. And that value is being created every minute; with every object harvested from a repository, the value of the wider aggregation grows. However, with even better metadata about what repositories contain, we can improve the efficacy of harvesting and ergo the value of the aggregation. We can improve the computational load endured by many aggregators by having better metadata -- a very relevant concern when we are all revisiting the energy footprint of our system infrastructures. But we can also enrich the quality of that data to make the wider aggregation even more useful. Think of the way this enrichment could benefit the 'data platform' ethos offered by the likes of CORE -- and then consider the impact this could have on the creation of new knowledge or data-based innovations.

Finalising Rioxx v3.0 has taken longer than expected. But its eventual introduction will be to add value to the quality of scholarly commons and the essential data platforms that underpin it.

Rioxx v3.0 Release Candidate 1 published

The Rioxx Governance Group (RGG) is pleased to announce the publication of the v3.0 Release Candidat 1 of Rioxx: The Research Outputs Metadata Schema -- formerly known as the RIOXX Metadata Application Profile.

Since July 2021, when the beta release of v3.0 was made available, the RGG has been working towards incorporating feedback from the repository and scholarly communications communities, and making adjustments to Rioxx to improve the way in which metadata are modelled. The publication of the candidate release today marks the end of this period of consultation but by no means the end -- it will always remain possible for anyone to document issues for future consideration at the Rioxx GitHub repository.

I would draw to the attention of readers the announcement made when the v3.0 beta release was published, as it provides a useful summary of some of the principal changes between v2.0 and v3.0. Importantly, the specific changes listed in the beta release remain in the candidate release too, which included some significant changes to the use of <dc:identifier> and <dc:relation>. But in this candidate release we have made some further significant updates:

Separation of project and grant data

The conflation of project and grant data has been a common problem across a number of metadata schema. Prior to this candidate release, Rioxx was no exception. Research projects can, and do, operate independently of grant funding. Similarly, not all grants result in the creation of a project. Moreover, some projects can persist for many years and receive multiple grants from multiple different funders; yet, many schema conflate projects and grants and thereby fail to accurately model reality. Greater separation of project and grant data is therefore something we have introduced as part of this candidate release, with the creation of <rioxxterms:grant> and the re-scoping of <rioxxterms:project>.

Wider use of persistent identifiers

A more inclusive approach to persistent identification and persistent identifiers (PIDs) across <rioxxterms:author>, <rioxxterms:contributor>, <rioxxterms:project> and <dc:publisher> has been introduced to reflect the growing maturity of the PID landscape. The v3.0 beta draft permitted a far narrower number of PID schemes. This has been addressed in the candidate release, with most extant schemes supported.

Rioxx name change

By now you will have released that the name has changed. As there exist many different repository metadata application profiles, it was not uncommon for the consultation process to elicit feedback from community members stating that the label 'RIOXX' was confusing, or that no-one could remember what the acronym stood for, or that the name of the profile failed to adequately communicate its purpose. Some even suggested that the name should be jettisoned altogether! We decided to keep the name, but we can at least make its full title a little more self-explanatory. We have thus elected to refine the name a little and de-acronymize 'RIOXX', since the acronym itself is no longer meaningful:

• Rioxx: The Research Outputs Metadata Schema

The name change helps to communicate the raison d'être of Rioxx: to facilitate the improved harvesting, aggregation and discovery of repository content. This change will be reflected in all future dissemination about Rioxx.

The future

But, of course, to truly facilitate improvements in harvesting, aggregation and discovery, Rioxx needs to be adopted by repositories. This is easier for some repositories to achieve than others, and easier for some organizational teams than others. Even teams with the technical nous may lack the team capacity to oil the wheels of adoption. The RGG is in discussions with a number of bodies and organizations about the possibility of supporting Rioxx v3.0. The shape of support remains uncertain at this stage but formal endorsement and/or technical support for repositories would be a welcome start. Further updates will be posted here in due course.

George Macgregor, RGG Chair - 2022-06-24

RIOXX metadata application profile v 3.0 beta draft released

Those of you following the status of RIOXX will be aware that a new governance group was formed in late 2019 under the auspices of UKCORR (RIOXX Governance Group - RGG). Following a period of consultation and review, the RGG is pleased to announce the publication of a beta draft of RIOXX v 3.0 for public comment.

v 3.0 delivers minor updates to refresh the profile but also includes some major changes, such as the removal of <ali:free_to_read> -- removed owing to inconsistent application across the sector and its creation of internal inconsistency in RIOXX; and the addition of a new property: <rioxxterms:record_public_release_date> to better model the deposit-exposure lifecycle of deposited digital resources. A significant alteration to the application of <dc:identifier> has also been introduced. We hope to better explain the rationale for specific changes in a forthcoming working paper or journal article, as well as re-articulate the benefits of RIOXX adoption for the purposes of discovery and aggregation. This will arrive in the near future.

In the meantime, we again solicit feedback from the community about the beta draft. Comments or issues can be raised through the RIOXX GitHub repository or by contacting the RGG Chair.

Readers are encouraged to review v 3.0 in its entirety; substantive changes can nevertheless be summarised as follows:

• <ali:license_ref>, <rioxxterms:author>, <rioxxterms:contributor>, <rioxxterms:project>, <rioxxterms:version_of_record> updated to explicitly note HTTPS use where URI values are specified.
• Removed the <ali:free_to_read> property.
• Removed the <rioxxterms:apc> property.
• Addition of the new property: <rioxxterms:record_public_release_date>, encoded according to ISO8601/W3CDTF.
• <rioxxterms:publication_date> updated to specify encoding as per ISO8601/W3CDTF, including resources with seasonal publication dates.
• Controlled list of types in <rioxxterms:type> removed and updated to specify the COAR Controlled Vocabulary Resource Type Genres.
• Replacement of XML 'id' attributes within properties with new 'uri' attribute.
• Modification to the application of <dc:identifier> and <dc:relation>.

Perhaps the most significant change in v 3.0 is the latter update relating to <dc:identifier> and <dc:relation>. It is a significant change because it departs from the convention established in prior versions of the profile whereby <dc:identifier> captured an identifier pointing to the actual resource being described by the RIOXX record (typically a file), rather than an intermediary resource such as a repository abstract page. RIOXX v 3.0 does not prohibit the continued use of <dc:identifier>in this way but instead recommends a change in its application and introduces new attributes to be used with <dc:relation> to accommodate multiple 'expressions' of the same 'work'. This is supplemented by the 'uri', 'deposit_date' and 'resource_exposed_date' attributes, and the 'type' attribute, the latter defined as per schema.org. This changes helps to communicate the HTTP(S) location of expressions.

More generally, RIOXX v 3.0 moves away from using the XML 'id' attribute across the profile to communicate URI(s) in instances where it is necessary to uniquely identify property content. This has resulted in the introduction of the 'uri' attribute as an alternative to 'id' which, in v 3.0, specifically affects <rioxxterms:author>, <rioxxterms:contributor>, <rioxxterms:publisher> and <rioxxterms:type>. The id attribute has strict usage under the W3C XML specification and it was acknowledged to be undesirable to expand its usage within v 3.0.

Striking a balance between the desire to data model perfectly and the need to keep the profile easily adoptable has been a difficult task for the RGG. A principal motivation for RIOXX and the work of the RGG was to facilitate the improved harvesting, aggregation and discovery of repository content -- and this is what we have tried to remain focused on. What is presented in v 3.0 may therefore be imperfect in certain respects but, within our parameters, nevertheless constitutes a useful update to the profile.

We welcome feedback!

New Governance Group and plans for revision to the profile

The RIOXX metadata application profile was developed for repositories to share metadata about the scholarly resources they contain. It has been deployed as a metadata application profile in approximately 70 institutional repositories in the UK, and (with support from Jisc) has software implementations in DSpace and ePrints.

The need for revision

While originally designed to meet the reporting requirements of Research Councils UK (RCUK), RIOXX has also proven to be generally useful as a standard for sharing metadata between repositories and network services such as large-scale metadata aggregators (e.g. Core). Feedback from such service providers has resulted in a short list of proposed changes and improvements to the RIOXX profile.

Governance

RIOXX (the profile, sources in the Github repository and documentation - including this website) have been maintained by Paul Walk at Antleaf for the last few years. Before developing the profile further, Antleaf has been keen to find a suitable and representative organisation to provide a governance role and to take oversight of any future revisions. Recently, the United Kingdom Council of Research Repositories (UKCORR) has formed a Governance Group to take responsibility for oversight of revisions to the RIOXX profile. UKCORR is perfectly placed to provide such governance because RIOXX is used predominately in the UK. The Governance Group has the following membership:

• George Macgregor, University of Strathclyde (Chair)
• Nicola Dowson, The Open University
• Michael Eadie, University of Glasgow
• Petr Knoth, Knowledge Media institute, The Open University (representing CORE)
• Kate O'Neill, University of Sheffield
• Paul Walk, Antleaf

Proposed process for revision

Antleaf proposes to manage a public consultation, open to any interested contributors, to invite suggestions for revisions to the RIOXX application profile, as well as any other relevant suggestions and comments. This will be conducted via the "Issues" feature on the RIOXX Github repository. There are already some suggestions for changes there, and we welcome more.

The process will be, roughly speaking:

• collect suggestions as Github issues
• encourage discussion on these issues and attempt to reach some consensus
• make a series of clear recommendations, based on the outcomes of these discussions, and invite the wider community to comment
• revise (as necessary) the recommendations, and offer the results to the RIOXX Governance Group for a decision

All of the above will be conducted with "radical openness": all discussion will take place in Github issues, and the minutes of the RIOXX Governance Group meetings are and will be publicly available.

If you have any interest in supporting open access, especially where this is facilitated by services such as Core which harvest and aggregate metadata and content from repositories, then please take a moment to consider how RIOXX might help, and feel free to join one or more of the discussions that have already started on Github.

Schema correction: rioxxterms:version_of_record

Pierre Lasou from Bibliothèque de l'Université Laval reported a 'bug' in RIOXX 2.0. While the documentation consistently refers to a property called 'rioxxterms:version_of_record', the schema XSD incorrectly includes a property called 'rioxxterms:version-of-record'.

I have updated the schema XSD to use the correct form - rioxxterms:version_of_record. This for two reasons:

1. underscores, rather than hyphens, are used consistently elsewhere in the RIOXX profile
2. the only examples of this property I can find 'in the wild' have used this version

So, for the avoidance of any doubt, the correct version to use is:

rioxxterms:version_of_record

RIOXX adoption reaches a half-century

I'm pleased to announce that the number of repositories which declare support for RIOXX has reached 50 (a half-century in cricket parlance). See the full list here

This number has grown steadily since January 2015 - quite an impressive rate of adoption. The repository systems which have implemented RIOXX are nearly all ePrints systems - but we expect the number of repositories to increase with support for DSpace coming soon.

RIOXX and metadata only records

I received the following query from Emma Sansby, Head of Library Services at Bishop Grosseteste University:

I am currently leading a project to implement Eprints (hosted and supported by ULCC) at my institution. We have the RIOXX plugin installed and I have a question about the licence_ref attribute.

I am creating a metadata-only journal article record into our repository which includes a DOI link to the publisher’s website. When I get to the RIOXX page I am forced to enter something under licence_ref as the attribute is mandatory, even though it’s a metadata-only record. What I’m not sure about is whether, with a metadata-only record, the licence information I enter needs to relate to the terms of use for the metadata itself, or to the terms of use for article out on the publisher’s website.

Can you provide any guidance?

A good question, and an interesting one!

My initial response to this would be to say that RIOXX is designed to allow reporting on the status of open access papers, and that without such a paper to describe, the RIOXX record is effectively meaningless. If the published version of a paper (the 'version of record') is itself open access, then the RIOXX record could describe that (the rioxxterms:version_of_record and the dc:identifier properties would contain the same value - a URL pointing to the open access paper.)

Is this sufficient answer to Emma's question? I'd be interested to hear what others think - especially if you have encountered this issue. Please feel free to leave a comment below - even if it is simply to say that this is also a concern for you.

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.

RIOXX and OAI PMH

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:

{BASE-URLl}?verb=ListRecords&from=2015-01-01&metadataPrefix=rioxx

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:

{BASE-URL}?verb=ListRecords&metadataPrefix=rioxx

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!