the RIOXX metadata application profile and guidelines

Profiles

Element Cardinality Description
Governance

In 2019, UKCORR took responsibility for hosting and supporting the newly-formed RIOXX Governance Group.

Membership

TBA

Group Charter

coming soon

Meeting Minutes

Governance Group Minutes - 2019-09-23

Monday 23 September 2019, 15:00

Attendees: George Macgregor (GM – Chair), Nicola Dowson (ND), Suzanne Atkins (SA), Petr Knoth (PK)

Apologies: Paul Walk (PW), Nancy Pontika (NP)

Actions arising

Four actions arose from the meeting. These are as follows:

  1. PK to liaise with Balviar Notay regarding Jisc involvement in the RGG, following a lack of feedback to several email approaches by GM. PK to feedback to the RGG.
  2. GM to mail the UKCORR list to recruit a member(s) to participate in the RGG; Nicola to (possibly) step aside.
  3. GM to liaise with PW/Antleaf to publish minutes, charter, etc. on RIOXX channels and publicise.
  4. GM to work with PW to publicise GitHub repository in order to solicit requirements / change requests.
  5. Welcome

GM welcomed attendees to the first RIOXX Governance Group (RGG) meeting and apologies were noted from PW and NP.

  1. Proposed meeting structure

GM summarised how future RGG meetings might be expected to be operate. Future meetings were likely to be determined by issues of RIOXX governance and that requirements gathered via the GitHub repository would define the agenda of meetings. GM indicated that he would provide brief minutes of the RGG meetings for circulation and eventual publication on the RIOXX website.

  1. RIOXX Charter

Several matters were arising from the agreed RIOXX Charter.

PK enquired about how requirements or suggested changes to RIOXX were expected to be considered by the RGG. GM reported that the Charter set out the procedures for capturing requirements. The RIOXX GitHub repository was to be the principal channel, with change requests, requirements, etc. collated and presented to the RGG for consideration. GitHub was the preference to ensure openness and transparency in the standard. PK agreed with the approach and noted that openness and transparency was vital.

PK observed that the frequency of RGG meetings was not enshrined in the Charter. GM expected initial RGG meetings to be frequent owing to RIOXX’s prior hiatus, but thereafter meetings would likely be responsive to issues arising via the GitHub repository. PK felt the ‘responsive’ approach was preferable and indicated that CORE would like to see the first round of changes approved sooner rather than later.

GM highlighted the issue of RGG membership, final membership for which remained outstanding. GM’s invitations to Jisc remained unanswered, despite follow-up messages. GM asked attendees whether Jisc involvement was essential and whether alternative umbrella bodies should be approached.

PK felt continued Jisc involvement was important. Attendees agreed. PK reported that he would been meeting with a Jisc representative in coming days (Balviar Notay) and would take this opportunity to seek clarity of the Jisc position. (ACTION)

GM also noted that the Charter proposed inviting one or two members from the wider UKCORR community to participate in the RGG. Members agreed that it was important to promote participation from this group and ND proposed stepping down in order to accommodate the new RGG members. GM indicated that he would contact the UKCORR list inviting RGG participation in due course. (ACTION)

  1. AOB

Openness in RGG business was an important aspect of the Charter. GM indicated that he would liaise with PW to have the Charter, RGG membership, minutes, etc. published via the RIOXX website or GitHub repository. (ACTION)

ND highlighted PW’s forthcoming appearance at the UKCORR event on 30 September as an opportunity to publicise the formation of the RGG and solicit requirements for the standard. GM noted that he would liaise with PW about publicising the GitHub repository too. (ACTION)

  1. DONM

TBC – although RGG members expressed a preference for the last week of October 2019. GM to circulate a Doodle poll in due course.

GM 24/09/2019

Home

This website contains technical and supporting information about the RIOXX Metadata Application Profile.

RIOXX is managed by Antleaf, and governed and supported by UKCORR.

News from 2013
News from 2014
News from 2015
News from 2018
Guidelines

The metadata guidelines explain how the RIOXX metadata application profile should be understood and implemented. The current version of the guidelines (PDF) is intended to support RIOXX 2.0

Crosswalk from RIOXX 2.0 to OpenAIRE 3.0

This crosswalk has been developed by the RIOXX team at EDINA in close collaboration with technical personnel at OpenAIRE. We would like to thank, in particular, Jochen Schirrwagen and Paolo Manghi for their assistance with this.

For guidance on the exact representation of properties within the OpenAIRE 3.0 metadata profile, please consult the documentation OpenAIRE Guidelines: For Literature Repositories

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RIOXX OpenAIRE Implementation
ali:free_to_read
Zero or one
dc:rights
One or more
This MUST be included, if available. 
ali:license_ref
One or more
dc:rights
One or more
This MUST be included, if available. 
dc:coverage
Zero or one
dc:coverage
Zero or more
This SHOULD be included, if available. 
dc:description
Zero or more
dc:description
zero or more
This MUST be included, if available. 
dc:format
Zero or more
dc:format
Zero or more
This SHOULD be included, if available. If provided in the RIOXX record, values will be in the form of MIME types
dc:identifier
Exactly one
dc:identifier
One or more
This MUST be included. This value will be in the form of an HTTP URI
dc:language
One or more
dc:language
Zero or more
This MUST be included. Values will be in the format specified by ISO 639–3
dc:publisher
Zero or more
dc:publisher
Zero or more
This MUST be included, if available. 
dc:relation
Zero or more
dc:relation
Zero or more
This SHOULD be included, if available. If provided in the RIOXX record, values will be in the form of HTTP URIs
dc:source
Zero or one
dc:source
Zero or more
This SHOULD be included, if available. If provided in the RIOXX record, the values will normally be in the form of an ISBN13 number (although this is not guaranteed)
dc:subject
Zero or more
dc:subject
Zero or more
This MUST be included, if available. 
dc:title
Exactly one
dc:title
One or more
This MUST be included. 
dcterms:dateAccepted
Exactly one
dc:date
One or more

This MUST be included. The RIOXX property (in ISO8601 ‘YYYY-MM-DD’ format) MUST be translated into the appropriate OpenAIRE URI (info:eu-repo/semantics/dateAccepted/YYYY-MM-DD).

Example: RIOXX property:

<dcterms:dateAccepted>
  2015-03-16
</dcterms:dateAccepted>

becomes OpenAIRE property:

<dc:date>
  info:eu-repo/semantics/dateAccepted/2015-03-16
</dc:date>
rioxxterms:apc
Zero or one
  This MUST NOT be included. There is no mapping from RIOXX to OpenAIRE for this property, so it MUST be ignored
rioxxterms:author
One or more
dc:creator
One or more

This MUST be included. Where the RIOXX property has the optional ID attribute included, this must be appended to the text content of the OpenAIRE property, parenthesised with square brackets.

Example: RIOXX property:

<rioxxterms:author id="http://orcid.org/0000-0002-1395-3092">
  Lawson, Gerald
</rioxxterms:author>

becomes OpenAIRE property:

<dc:creator>
  Lawson, Gerald [http://orcid.org/0000-0002-1395-3092]
</dc:creator>
rioxxterms:contributor
Zero or more
dc:contributor
Zero or more

This SHOULD be included, if available. Where the RIOXX property has the optional ID attribute included, this must be appended to the text content of the OpenAIRE property, parenthesised with square brackets.

Example: RIOXX property:

<rioxxterms:contributor id="http://isni.org/isni/0000000419367988">
  University of Edinburgh
</rioxxterms:contributor>

becomes OpenAIRE property:

<dc:contributor>
  University of Edinburgh [http://isni.org/isni/0000000419367988]
</dc:contributor>
rioxxterms:project
One or one
dc:relation
Zero or more

This MUST be included. The RIOXX property includes the ‘project ID’ as provided by the funder. Funding information available and supported by OpenAIRE can be found at http://api.openaire.eu/. Where the funder is the European Commision, the mapping will be carried out as indicated in the following example:

RIOXX property:

<rioxxterms:project
  funder_name="European Commission"
  funder_id="http://isni.org/isni/000000012162673X"
>
  info:eu-repo/grantAgreement/EC/FP7/244909/EU/Making Capabilities Work/WorkAble
</rioxxterms:project>

becomes OpenAIRE property:

<dc:relation>
  info:eu-repo/grantAgreement/EC/FP7/244909/EU/Making Capabilities Work/WorkAble
</dc:relation>
rioxxterms:publication_date
Zero or one
dc:date
One or more

This MUST be included, if available and in a compatible format. If the RIOXX property is provided in ISO8601 ‘YYYY-MM-DD’ format then MUST be simply mapped into the OpenAIRE dc:date property

Example: RIOXX property:

<rioxxterms:publication_date>
  2015-03-16
</rioxxterms:publication_date>

becomes OpenAIRE property:

<dc:date>
  2015-03-16
</dc:date>

or, RIOXX property:

<rioxxterms:publication_date>
  2015
</rioxxterms:publication_date>

becomes OpenAIRE property:

<dc:date>
  2015
</dc:date>

However, rioxxterms:publication_date does not constrain the format of its values so entries such as ‘Spring, 2015’, while not permissible in OpenAIRE, are perfectly possible in RIOXX. In such cases, the mapping process may choose to parse the permissible value from the RIOXX property to use in the OpenAIRE property - so:

RIOXX property:

<rioxxterms:publication_date>
  Spring, 2015
</rioxxterms:publication_date>

becomes OpenAIRE property:

<dc:date>
  2015
</dc:date>
rioxxterms:type
One or one
dc:type
One or more
This MUST be included. This must use the controlled vocabulary mapping specified below in the table called Vocabulary mapping: Publication Types
rioxxterms:version
One exactly
dc:relation
One exactly
This MUST be included. This must use the controlled vocabulary mapping specified below in the table called Vocabulary mapping: Publication Versions
rioxxterms:version_of_record
Zero or one
dc:relation
Zero or more
This MUST be included, if available. If provided in the RIOXX record, value will be in the form of an HTTP URI



Vocabulary mapping: Publication Types

RIOXX OpenAIRE Notes
Book info:eu-repo/semantics/book  
Book Chapter info:eu-repo/semantics/bookPart  
Conference Paper/Proceeding/Abstract info:eu-repo/semantics/conferenceObject  
Journal Article/Review info:eu-repo/semantics/article  
Manual/Guide info:eu-repo/semantics/technicalDocumentation  
Monograph info:eu-repo/semantics/book  
Policy Briefing Report info:eu-repo/semantics/report  
Technical Report info:eu-repo/semantics/report  
Technical Standard info:eu-repo/semantics/other  
Thesis info:eu-repo/semantics/other OpenAIRE provides:

  • info:eu-repo/semantics/bachelorThesis
  • info:eu-repo/semantics/masterThesis
  • info:eu-repo/semantics/doctoralThesis

but since it is impossible to select from these based on the RIOXX term, it would be potentially misleading to use one of these OpenAIRE terms

Other info:eu-repo/semantics/other  
Consultancy Report info:eu-repo/semantics/report  
Working Paper info:eu-repo/semantics/workingPaper  



Vocabulary mapping: Publication Versions

RIOXX OpenAIRE Notes
AO = Author's Original info:eu-repo/semantics/authorVersion  
SMUR = Submitted Manuscript Under Review info:eu-repo/semantics/submittedVersion  
AM = Accepted Manuscript info:eu-repo/semantics/acceptedVersion  
P = Proof There is no eqivalent OpenAIRE term for this.
VoR = Version of Record info:eu-repo/semantics/publishedVersion  
CVoR = Corrected Version of Record info:eu-repo/semantics/updatedVersion  
EVoR = Enhanced Version of Record info:eu-repo/semantics/updatedVersion  
NA = Not Applicable (or Unknown) info:eu-repo/semantics/updatedVersion  

News
About

The RIOXX metadata application profile was developed for institutional repositories to share metadata about the scholarly resources they contain. 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).

RIOXX focuses on applying consistency to the metadata fields used for identifiers of scholarly outputs, people and organisations, research funders and project/grants, and is designed to support the consistent tracking of open-access research publications across scholarly systems.

The RIOXX metadata application profile and its documentation (this website) is maintained by Paul Walk at Antleaf.

Email: paul@paulwalk.net

History

The RIOXX metadata application profile was originally developed by Paul Walk (while at UKOLN) and then EDINA) and by Sheridan Brown (Chygrove Ltd), working closely with RCUK who acted as sponsor and in collaboration with HEFCE who supported and endorsed this work. This original work was funded and supported by Jisc.

Historical endorsements

"The RIOXX guidelines offer clear and practical guidance to organisations wanting to attribute research outcome information to specific funders and research grants in their repositories."

"The RIOXX metadata application profile has been developed with input from HEFCE to help repositories to comply with the open access policy for the next REF. We support its uptake and use."

"It is important for UK universities to start to plan to engage and implement the RIOXX metadata application profile as soon as possible as it will support greater automation of collection of information on publications and other research outcomes."

Since then, with the loss of both RCUK and HEFCE, RIOXX has been maintained by Paul Walk at Antleaf.


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.

RCUK RIOXX Application Profile Version 1.0 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is the first release of the RIOXX application profile, version 1.0. There are no changes from the previous draft version (0.91)

This section details the application profile for RIOXX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 1.1 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX applicaiton profile, enhanced following the outcomes of the V4OA project.

Changes since version 1.0

  • the <free_to_read> element has been added
  • the <license_ref> element has been added
  • the <dc:rights> element has been removed - the introduction of the new <license_ref> has superceded this
  • the recommendations for the <rioxxterms:funder> element have changed - the use of FundRef is now recommended.
  • the <rioxxterms:apc> element has been added
  • the <rioxxterms:version> element has been added

Note that we may introduce a controlled voicabulary of output types into this version, if RCUK can supply an authoritative list. This would then constrain the values of the <dc:rights> element

This section details the application profile for RIOXX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 1.2a (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX applicaiton profile, enhanced following the outcomes of the V4OA project.

Changes since version 1.0

  • the <free_to_read> element has been added
  • the <license_ref> element has been added
  • the <dc:rights> element has been removed - the introduction of the new <license_ref> has superceded this
  • the recommendations for the <rioxxterms:funder> element have changed - the use of FundRef is now recommended.
  • the <rioxxterms:apc> element has been added
  • the <rioxxterms:version> element has been added
  • the <rioxxterms:creator> element has been replaced with <rioxxterms:author>
  • the <rioxxterms:funder> element now has an id attribute
  • the <rioxxterms:version-of-record> element has been added

Note that we may introduce a controlled voicabulary of output types into this version, if RCUK can supply an authoritative list. This would then constrain the values of the <dc:rights> element

This section details the application profile for RIOXX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 1.3 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX applicaiton profile, enhanced following the outcomes of the V4OA project.

Changes since version 1.0

  • the <free_to_read> element has been added
  • the <license_ref> element has been added
  • the <dc:rights> element has been removed - the introduction of the new <license_ref> has superceded this
  • the recommendations for the <rioxxterms:funder> element have changed - the use of FundRef is now recommended.
  • the <rioxxterms:apc> element has been added
  • the <rioxxterms:version> element has been added
  • the <rioxxterms:creator> element has been replaced with <rioxxterms:author>
  • the new <rioxxterms:project> element has replaced both <rioxxterms:projectid> and <rioxxterms:funder>
  • the <rioxxterms:version-of-record> element has been added, and the recommendation to include, under <dc:relation>, the DOI to the version of record has been removed.
  • the <dcterms:issued> element has been replaced with the <rioxxterms:acceptdate> and the meaning of this element has changed.

Note that we may introduce a controlled vocabulary of output types into this version, if RCUK can supply an authoritative list. This would then constrain the values of the <dc:rights> element

This section details the application profile for RIOXX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 1.4 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX application profile, enhanced following the outcomes of the V4OA project.

Changes since version 1.0

  • the <free_to_read> element has been added
  • the <license_ref> element has been added
  • the <dc:rights> element has been removed - the introduction of the new <license_ref> has superceded this
  • the recommendations for the <rioxxterms:funder> element have changed - the use of FundRef is now recommended.
  • the <rioxxterms:apc> element has been added
  • the <rioxxterms:version> element has been added
  • the <rioxxterms:creator> element has been replaced with <rioxxterms:author>
  • the new <rioxxterms:project> element has replaced both <rioxxterms:projectid> and <rioxxterms:funder>
  • the <rioxxterms:version-of-record> element has been added, and the recommendation to include, under <dc:relation>, the DOI to the version of record has been removed.
  • the <dcterms:issued> element has been replaced with the <rioxxterms:acceptdate> and the meaning of this element has changed.

Terminology

the resource refers to the electronic copy of an article held in a repository, and is the thing being described by the RIOXX metadata record.

version of record refers to the instance of the article being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 1.5 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX application profile, enhanced following the outcomes of the V4OA project.

Changes since version 1.0

  • the <free_to_read> element has been added
  • the <license_ref> element has been added
  • the <dc:rights> element has been removed - the introduction of the new <license_ref> has superceded this
  • the recommendations for the <rioxxterms:funder> element have changed - the use of FundRef is now recommended.
  • the <rioxxterms:apc> element has been added
  • the <rioxxterms:version> element has been added
  • the <rioxxterms:creator> element has been replaced with <rioxxterms:author>
  • the new <rioxxterms:project> element has replaced both <rioxxterms:projectid> and <rioxxterms:funder>
  • the <rioxxterms:version_of_record> element has been added, and the recommendation to include, under <dc:relation>, the DOI to the version of record has been removed.
  • the <dcterms:issued> element has been replaced with the <dcterms:dateAccepted> and the meaning of this element has changed.
  • the <dc:type> element has been replaced with the <rioxxterms:type> and this element has been constrained with a controlled list of allowed values.
  • the <dcterms:audience> element has been removed.
  • the <dcterms:references> element has been removed.
  • <rioxxterms:publication_date> has been added

Terminology

the resource refers to the electronic copy of an article held in a repository, and is the thing being described by the RIOXX metadata record.

version of record refers to the instance of the article being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 2.0 Final

This is the final release of RCUK RIOXX application profile version 2.0. For more details on changes see the release notes.

XSD Schema files and documentation to support this application profile are available.

Terminology

the resource refers to the electronic copy of a publication held in a repository, and is that which is being described by the RIOXX metadata record.

version of record refers to the version of the publication being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 2.0 RC 1 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX application profile, enhanced following the public consultation. For more details on changes see the release notes

Terminology

the resource refers to the electronic copy of a publication held in a repository, and is that which is being described by the RIOXX metadata record.

version of record refers to the version of the publication being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 2.0 RC 2 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX application profile. For more details on changes see the release notes

Terminology

the resource refers to the electronic copy of a publication held in a repository, and is that which is being described by the RIOXX metadata record.

version of record refers to the version of the publication being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RCUK RIOXX Application Profile Version 2.0 beta 1 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This is an updated version of the RIOXX application profile, enhanced following the outcomes of the V4OA project. For more details on changes see the release notes

Terminology

the resource refers to the electronic copy of a publication held in a repository, and is that which is being described by the RIOXX metadata record.

version of record refers to the version of the publication being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

RIOXX Basic Application Profile Version 2.0 Final

This is the RIOXX 'basic' application profile version 2.0. This is not the full, RCUK-approved application profile, but is a description of the basic RIOXX syntax only. The basic RIOXX application-profile is somewhat less strict than the RCUK application profile.

Terminology

the resource refers to the electronic copy of a publication held in a repository, and is that which is being described by the RIOXX metadata record.

version of record refers to the version of the publication being described in the RIOXX metadata record which has been made available, electronically, by the publisher.

The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in the table below should be interpreted as described in RFC 2119.

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-url>?verb=ListRecords&from=2015-01-01&metadataPrefix=rioxx

where 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!

All Rights Reserved (Under Embargo)
Licenses
All Rights Reserved
Release Notes

Version 2.0 Final Release

Changes since version 2.0 RC 2

  • changed <dcterms:dateAccepted> to only allow YYYY-MM-DD and not YYYY-MM

Version 2.0 RC 2

Changes since version 2.0 beta 1

  • changed <dcterms:dateAccepted> to only allow YYYY-MM and not YYYY
  • very slight change to wording in <dc:identifier>
  • recommendation to use ISBN13 rather than book title in dc:source
  • removed description of dc:subject and pointed to OpenAIRE guidelines
  • added the ali namespace prefix to <license_ref> and <free_to_read>
  • added recommendation to use ISNI for identification of funders, as well as for authors and contributors where these are organisations

Version 2.0 RC 1

This version was never published, but was used for further consultation with stakeholders

Version 2.0 beta 1

This is an updated version of the RIOXX application profile, enhanced following the outcomes of the V4OA project.

Changes since version 1.0

  • the <free_to_read> element has been added
  • the <license_ref> element has been added
  • the <dc:rights> element has been removed - the introduction of the new <license_ref> has superseded this
  • the recommendations for the <rioxxterms:funder> element have changed - the use of FundRef is now recommended.
  • the <rioxxterms:apc> element has been added
  • the <rioxxterms:version> element has been added
  • the <rioxxterms:creator> element has been replaced with <rioxxterms:author>
  • the new <rioxxterms:project> element has replaced both <rioxxterms:projectid> and <rioxxterms:funder>
  • the <rioxxterms:version_of_record> element has been added, and the recommendation to include, under <dc:relation>, the DOI to the version of record has been removed.
  • the <dcterms:issued> element has been replaced with the <dcterms:dateAccepted>.
  • the <dc:type> element has been replaced with the <rioxxterms:type> and this element has been constrained with a controlled list of allowed values.
  • the <dcterms:audience> element has been removed.
  • the <dcterms:references> element has been removed.
  • <rioxxterms:publication_date> has been added

Version 1.0

This is the initial release of the RIOXX application profile

Implementation

The RIOXX Metadata Application Profile has been implemented in a number of systems. This page provides links to:

Software components

EPrints repository plugin

This plugin is funded and supported by Jisc. It adds the following functionality to an EPrints repository:

  • capture of additional metadata required by the RIOXX application profile
  • measurement of RIOXX compliance across the repository
  • exposure of RIOXX-compliant XML records (via OAI-PMH) for sharing with funders and governing bodies

The plugin can be installed from the EPrints Bazaar. The source-code is available on GitHub.

DSpace (versions 3,4 or 5) repository patches

These patches are funded and supported by Jisc. They add the following functionality to a DSpace respository:

  • RIOXX-related fields in the submission forms
  • a way to expose only RIOXX-compliant items
  • live lookup into the Fundref registry for funder identifiers

The patches are available on request by email to info@atmire.com.


Systems consuming RIOXX metadata

One Repo

The One Repo is a platform which "aims to make the entire open-access scholarly record available via a Web UI, embeddable widgets and various web-services, as well providing all of the metadata for direct download".

CORE

CORE is a harvesting and aggregation system which offers "seamless access to millions of open access research papers" and provides value-added services from this aggregation.

RCUK RIOXX Application Profile Version 0.8 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

Element Inclusion Description Roadmap  
dc:title Mandatory This refers to the resource’s title and any sub-titles. Title should be entered using free text. Title is the form of words by which a resource will be formally known and should be represented using the original spelling and wording. The recommended format for expressing subtitles is Title:Subtitle  
dc:creator Mandatory The creator of a resource may be a person, organisation or service. Where there is more than one creator, use a separate dc:creator element for each one. Enter as many creators as required. If the creator is a person and it is desired to record that person's affiliation, the affiliation should be recorded as a dc:contributor element (see below). Where the creator is a person, the recommended format is either to add text in the form Last Name, First Name(s),  or to add a unique identifier from a recognised system such as ORCID. ORCID IDs should be entered in their HTTP URI form, e.g. http://orcid.org/0000-0003-1541-5631  
dc:identifier Mandatory A globally unique identifier for the resource. The use of an HTTP URI that can be de-referenced (and is, thus, actionable) is recommended. A commonly-used example is a publisher’s DOI, in it's HTTP form - e.g. http://dx.doi.org/10.1006/jmbi.1995.0238 It is strongly recommended that this identifier should point to the actual resource being described by a RIOXX record (typically a PDF file), rather than to an intermediary resource such as a repository web page. We anticipate future work to support repositories in making this identifier point reliably to the resource being described, rather than to, for example, an intermediate web page.
dc:source Mandatory The source label describes a resource from which the current resource is derived (in whole or in part). It is recommended that the source is referenced using a unique identifier from a recognised system e.g. the unique 8-digit International Standard Serial Numbers (ISSN) assigned to print and electronic periodicals.  
dc:language Mandatory This refers to the primary language in which the content of the resource is presented. The element can be repeated if the resource contains multiple languages. A coded value or text string may be used. It is, however, recommended that the values used for this element conform to ISO 639-3. This offers two and three letter tags e.g. “en” or “eng” for English and “en-GB” for English used in the UK.  
rioxxterms:projectid Mandatory This is an addition to Dublin Core’s fifteen generic elements and is designed to collect the grant numbers issued by funders to Principal Investigators that relate to the current resource. It is mandatory to use the alphanumeric identifier provided by the funder in its original format e.g. ST/K001234/1 (denoting an STFC award). Sometimes publications have more than one funder associated with them; these should be recorded using separate iterations of rioxxterms.projectid. In cases where projects have been funded internally, use whichever internal code is appropriate.  
rioxxterms:funder Mandatory This is an addition to Dublin Core’s fifteen generic elements and is designed to collect the funder’s name. It is recommended that you use free text to record the funder’s name in its preferred format (normally that indicated in the grant award notice). Work is under way to facilitate access to an international directory of funder names. When this becomes available it will be mandatory to use the unique funder identity number described in the directory.
dcterms:issued Mandatory The publication date of the resource. It is recommended that date is encoded using ISO 8601 (post-2004 versions) which follows the following format: YYYY-MM-DD. Year (YYYY) or year and month (YYYY-MM) may be used if the full date is not known.  
dc:format Recommended This refers to the form of the resource, physical or digital and can refer to the media-type or dimensions of the resource. It is recommended that the IANA registered list of Internet Media Types (MIME types) be used. If more than one category is needed to describe a single resource, use separate iterations of the dc:format element.  
dc:publisher Recommended A free text string giving the name of the entity responsible for making the version of record of a resource available. This could be a person, organisation or service.  
dc:description Recommended This field may be indexed and its contents presented to people conducting searches. The goal is to describe the content of the resource using free text. It is recommended that an English language abstract be used where available. HTML or other markup tags should not be included in this field.  
dc:subject Recommended Normally keywords, phrases or classification codes are used to describe the topic of the resource. If using free text, avoid using general keywords. The recommendation is to use a formal classification scheme or controlled vocabulary e.g Library of Congress Classification Numbers or Medical Subject Headings (MeSH). When including terms from multiple vocabularies, use separate element iterations. If multiple vocabulary terms or keywords are used, either separate terms with semi-colons or use separate iterations of the Subject element.  
dc:coverage Optional This refers to the scope or extent of the content of the resource. It may include jurisdictional, temporal or spatial information. It is recommended that, where possible, a recognised globally unique identifier is used, such as the Thesaurus of Geographic Names, but free text may be used. For example, the place of publication may be recorded.  
dc:rights Optional At present there is no agreed vocabulary that describes intellectual property or other property rights with respect to open access full text resources. This field is commonly ignored at present. Work is under way to develop consensus on a controlled vocabulary that describes rights to open access items as well as the associated issues of Creative Commons licenses and embargo periods. Once this work concludes the appropriate use of this element is expected to become mandatory.
dc:audience Optional This field is designed to contain information about the group for which the resource is intended or useful. There are no established vocabularies but sometimes creators or publishers indicate the intended audience. Note that the Research Outcomes System (ROS) used by most of the UK’s Research Councils track whether a resource is for a “non-academic audience” (with a drop-down list of possible selections) and whether a resource is for an “international audience”. In the absence of alternative formal vocabularies, following the ROS lead is a reasonable course of action. The development of a controlled vocabulary for audience is likely to be recommended for Phase 2 of the RIOXX project.
dc:type Optional Type refers to the nature or genre of the content of the resource and can be entered as free text. Take care not to confuse this with dc:format. The development of a controlled vocabulary is likely to be recommended for Phase 2 of the RIOXX project.
dc:contributor Optional This element is designed to describe the entity – for example the name of a person, organisation or service – responsible for making contributions to the content of the resource. Enter as many dc:contributor elements as required. If the contributor is a person and it is desired to record that person's affiliation, the affiliation should be recorded as a separate dc:contributor element. Where the contributor is a person, the recommended format is either to add text in the form Last Name, First Name(s),  or to add a unique identifier from a recognised system such as ORCID. ORCID IDs should be entered in their HTTP URI form, e.g. http://orcid.org/0000-0003-1541-5631  
RCUK RIOXX Application Profile Version 0.9 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This section details the application profile for RIOXX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Element Cardinality  Description Roadmap
dc:creator One or more. Mandatory
The creator of a resource may be a person, organisation or service. Where there is more than one creator, a separate dc:creator element MUST be used for each one. As many creators may be entered as required. If the creator is a person and it is desired to record that person’s affiliation, the affiliation SHOULD be recorded as a dc:contributor element (see dc:contributor). This element SHOULD take an optional attribute called id, designed to hold a machine-readable and unique identifier, if available, for the creator. Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically. The ideal use of this element is to include both a machine-readable ID in the id attribute, and a text string in the body of the element, thus:
<dc:creator id=”identifier-for-this-creator-entity”>
    name-of-this-creator-entity
</dc:creator>
Where the creator is a person, the RECOMMENDED format is to add text in the form Last Name, First Name(s), and to include an ORCID ID, if known, in its HTTP URI form, e.g.
<dc:creator id=”http://orcid.org/0000-0002-1395-3092”>
    Lawson, Gerald
</dc:creator>
 
dc:identifier Exactly one. Mandatory
This field MUST contain a globally unique and persistent identifier for the resource being described. The identifier SHOULD be an HTTP URI that can be de-referenced (and is, thus, actionable). The purpose of this field is to allow access to the resource, therefore it is RECOMMENDED that this identifier should point to the actual resource being described by the RIOXX record (typically a PDF file), rather than to an intermediary resource such as a repository web page. This resource SHOULD be a version of the resource held in the local repository.
 
dc:language One or more. Mandatory
This refers to the primary language in which the content of the resource is presented. The element MAY be repeated if the resource contains multiple languages. Values used for this element MUST conform to ISO 639–3. This offers two and three letter tags e.g. “en” or “eng” for English and “en-GB” for English used in the UK.
 
dc:source Exactly one. Mandatory
The source label describes a resource from which the current resource is derived (in whole or in part). It is RECOMMENDED that the source is referenced using a unique identifier from a recognised system e.g. the unique 8-digit International Standard Serial Numbers (ISSN) assigned to print and electronic periodicals.
 
dc:title Exactly one. Mandatory
This refers to the resource’s title and any sub-titles. The title is the form of words by which a resource will be formally known and should be represented using the original spelling and wording. The RECOMMENDED format for expressing subtitles is Title:Subtitle
 
dcterms:issued Exactly one. Mandatory
The publication date of the resource. The date SHOULD be encoded using ISO 8601 (post–2004 versions) which follows the following format: YYYY-MM-DD. Year (YYYY) or year and month (YYYY-MM) MAY be used if the full date is not known.
 
rioxxterms:funder One or more. Mandatory
The canonical name of the entity responsible for funding the resource being described by this RIOXX record MUST be recorded here as text. Where more than one funder exists, each MUST be entered as a separate instance of this field. A controlled list of funder names SHOULD be used. A list has been provided for this purpose and is available through the RIOXX web site at http://docs.rioxx.net/funders/
 
rioxxterms:projectid One or more. Mandatory
This is designed to collect the project IDs issued by funders that relate to the current resource. It is REQUIRED to use the alphanumeric identifier provided by the funder in its original format e.g. ST/K001234/1. Sometimes publications have more than one project ID associated with them; these MUST be recorded using separate instances of rioxxterms.projectid. In cases where projects have been funded internally, use whichever internal code is appropriate.
 
dc:description Zero or more. Recommended
This field may be indexed and its contents presented to people conducting searches. The goal is to describe the content of the resource using free text. It is RECOMMENDED that an English language abstract be used where available. HTML or other markup tags SHOULD NOT be included in this field.
 
dc:format Zero or one. Recommended
This refers to the form of the resource being described in the RIOXX record. The resource can be physical or digital and therefore this element can refer to the media-type or dimensions of that resource. Where the resource being described is digital, the MIME type of the object pointed to by this RIOXX record’s dc:identifier element MUST be entered here.
 
dc:publisher Zero or more. Recommended
A free text string giving the name of the entity responsible for making the version of record of a resource available. This could be a person, organisation or service.
 
dc:rights Zero or one Recommended
It is RECOMMENDED that a URL to an appropriate Creative Commons license is used here, for example: http://creativecommons.org/licenses/by-sa/3.0/deed.en_GB
Work is under way to develop consensus on a controlled vocabulary that describes rights to open access items as well as the associated issues of Creative Commons licenses and embargo periods. Once this work concludes an expression of rights and licensing is expected to become mandatory.
dc:subject Zero or more. Recommended
Normally keywords, phrases or classification codes are used to describe the topic of the resource. If using free text, the use of general keywords SHOULD be avoided. It is RECOMMENDED to use a formal classification scheme or controlled vocabulary e.g Library of Congress Classification Headings or Medical Subject Headings (MeSH). When including terms from multiple vocabularies, separate element iterations MUST be used. If multiple vocabulary terms or keywords are used, terms SHOULD be separated with one of the following approaches:
  • the use of semi-colons to separate individual terms
or
  • the use of separate iterations of this element for each term.
 
dc:audience Zero or more. Optional
This field is designed to contain information about the group for which the resource is intended or is considered to be useful. There is no controlled vocabulary for this but sometimes creators or publishers indicate the intended audience. Note that the Research Outcomes System (ROS) used by most of the UK’s Research Councils tracks whether a resource is for a “non-academic audience” (with a drop-down list of possible selections) and whether a resource is for an “international audience”. In the absence of alternative formal vocabularies, following the ROS lead is a reasonable course of action.
The introduction of a controlled vocabulary for audience will be proposed for phase 2 of the RIOXX project, subject to funding.
dc:contributor Zero or more. Optional
This field is designed to describe an entity – for example the name of a person, organisation or service – responsible for making contributions to the content of the resource. As many dc:contributor elements may be entered as required. If the contributor is a person and it is desired to record that person's affiliation, the affiliation MUST be recorded as a separate dc:contributor element. This element SHOULD take an optional attribute called id, designed to hold a machine-readable and unique identifier, if available, for the contributor. Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically. The ideal use of this element is to include both a machine-readable ID in the id attribute, and a text string in the body of the element, thus:
<dc:contributor id=”identifier-for-this-contributor-entity”>
    name-of-this-contributor-entity
</dc:contributor>
Where the contributor is a person, the RECOMMENDED format is to add text in the form Last Name, First Name(s), and to include an ORCID ID, if known, in its HTTP URI form, e.g.
<dc:contributor id=”http://orcid.org/0000-0002-1395-3092”>
    Lawson, Gerald
</dc:contributor>
 
dc:coverage Zero or more. Optional
This refers to the scope or extent of the content of the resource. It may include jurisdictional, temporal or spatial information. It is RECOMMENDED that, where possible, a recognised globally unique identifier is used, such as the Thesaurus of Geographic Names. For example, the place of publication may be recorded.
 
dc:type Zero or more. Optional
Type refers to the nature or genre of the content of the resource and can be entered as free text. Take care not to confuse this with dc:format.
The introduction of a controlled vocabulary for 'type' will be proposed for phase 2 of the RIOXX project, subject to funding.
dc.relation Zero or more. Optional
This format of this element SHOULD be an HTTP URI which points to a related resource. It is RECOMMENDED that, where available, the publisher’s DOI for the main resource being described in the RIOXX record also be entered here, in it’s HTTP form – e.g. http://dx.doi.org/10.1006/jmbi.1995.0238 Each related resource MUST appear as a separate instance of the field.
 
dcterms:references Zero or more. Optional
The format of this element SHOULD be an HTTP URI which points to a resource referenced by the resource described in the RIOXX record. Common examples might include a data-set which underpins a paper being described in the record. Each reference MUST appear as a separate instance of this element.
 
RCUK RIOXX Application Profile Version 0.91 (DEPRECATED)

Note that there is a newer version of the application profile - please check here for the latest version

This version, 0.91, is a minor update from version 0.9
A stable version, 1.0, will be published once testing has been completed - this is ongoing and scheduled to be completed at the end of April.

Changes from version 0.9

  • dc:creator is now rioxxterms:creator
  • dc:contributor is now rioxxterms:contributor
  • dc:audience is now dcterms:audience

This section details the application profile for RIOXX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Element Cardinality  Description Roadmap
rioxxterms:creator One or more. Mandatory
The creator of a resource may be a person, organisation or service. Where there is more than one creator, a separate rioxxterms:creator element MUST be used for each one. As many creators may be entered as required. If the creator is a person and it is desired to record that person’s affiliation, the affiliation SHOULD be recorded as a rioxxterms:creator element (see rioxxterms:creator). This element SHOULD take an optional attribute called id, designed to hold a machine-readable and unique identifier, if available, for the creator. Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically. The ideal use of this element is to include both a machine-readable ID in the id attribute, and a text string in the body of the element, thus:
<rioxxterms:creator id=”identifier-for-this-creator-entity”>
    name-of-this-creator-entity
</rioxxterms:creator>
Where the creator is a person, the RECOMMENDED format is to add text in the form Last Name, First Name(s), and to include an ORCID ID, if known, in its HTTP URI form, e.g.
<rioxxterms:creator id=”http://orcid.org/0000-0002-1395-3092”>
    Lawson, Gerald
</rioxxterms:creator>
 
dc:identifier Exactly one. Mandatory
This field MUST contain a globally unique and persistent identifier for the resource being described. The identifier SHOULD be an HTTP URI that can be de-referenced (and is, thus, actionable). The purpose of this field is to allow access to the resource, therefore it is RECOMMENDED that this identifier should point to the actual resource being described by the RIOXX record (typically a PDF file), rather than to an intermediary resource such as a repository web page. This resource SHOULD be a version of the resource held in the local repository.
 
dc:language One or more. Mandatory
This refers to the primary language in which the content of the resource is presented. The element MAY be repeated if the resource contains multiple languages. Values used for this element MUST conform to ISO 639–3. This offers two and three letter tags e.g. “en” or “eng” for English and “en-GB” for English used in the UK.
 
dc:source Exactly one. Mandatory
The source label describes a resource from which the current resource is derived (in whole or in part). It is RECOMMENDED that the source is referenced using a unique identifier from a recognised system e.g. the unique 8-digit International Standard Serial Numbers (ISSN) assigned to print and electronic periodicals.
 
dc:title Exactly one. Mandatory
This refers to the resource’s title and any sub-titles. The title is the form of words by which a resource will be formally known and should be represented using the original spelling and wording. The RECOMMENDED format for expressing subtitles is Title:Subtitle
 
dcterms:issued Exactly one. Mandatory
The publication date of the resource. The date SHOULD be encoded using ISO 8601 (post–2004 versions) which follows the following format: YYYY-MM-DD. Year (YYYY) or year and month (YYYY-MM) MAY be used if the full date is not known.
 
rioxxterms:funder One or more. Mandatory
The canonical name of the entity responsible for funding the resource being described by this RIOXX record MUST be recorded here as text. Where more than one funder exists, each MUST be entered as a separate instance of this field. A controlled list of funder names SHOULD be used. A list has been provided for this purpose and is available through the RIOXX web site at http://docs.rioxx.net/funders/
 
rioxxterms:projectid One or more. Mandatory
This is designed to collect the project IDs issued by funders that relate to the current resource. It is REQUIRED to use the alphanumeric identifier provided by the funder in its original format e.g. ST/K001234/1. Sometimes publications have more than one project ID associated with them; these MUST be recorded using separate instances of rioxxterms.projectid. In cases where projects have been funded internally, use whichever internal code is appropriate.
 
dc:description Zero or more. Recommended
This field may be indexed and its contents presented to people conducting searches. The goal is to describe the content of the resource using free text. It is RECOMMENDED that an English language abstract be used where available. HTML or other markup tags SHOULD NOT be included in this field.
 
dc:format Zero or one. Recommended
This refers to the form of the resource being described in the RIOXX record. The resource can be physical or digital and therefore this element can refer to the media-type or dimensions of that resource. Where the resource being described is digital, the MIME type of the object pointed to by this RIOXX record’s dc:identifier element MUST be entered here.
 
dc:publisher Zero or more. Recommended
A free text string giving the name of the entity responsible for making the version of record of a resource available. This could be a person, organisation or service.
 
dc:rights Zero or one Recommended
It is RECOMMENDED that a URL to an appropriate Creative Commons license is used here, for example: http://creativecommons.org/licenses/by-sa/3.0/deed.en_GB
Work is under way to develop consensus on a controlled vocabulary that describes rights to open access items as well as the associated issues of Creative Commons licenses and embargo periods. Once this work concludes an expression of rights and licensing is expected to become mandatory.
dc:subject Zero or more. Recommended
Normally keywords, phrases or classification codes are used to describe the topic of the resource. If using free text, the use of general keywords SHOULD be avoided. It is RECOMMENDED to use a formal classification scheme or controlled vocabulary e.g Library of Congress Classification Headings or Medical Subject Headings (MeSH). When including terms from multiple vocabularies, separate element iterations MUST be used. If multiple vocabulary terms or keywords are used, terms SHOULD be separated with one of the following approaches:
  • the use of semi-colons to separate individual terms
or
  • the use of separate iterations of this element for each term.
 
dcterms:audience Zero or more. Optional
This field is designed to contain information about the group for which the resource is intended or is considered to be useful. There is no controlled vocabulary for this but sometimes creators or publishers indicate the intended audience. Note that the Research Outcomes System (ROS) used by most of the UK’s Research Councils tracks whether a resource is for a "non-academic audience" (with a drop-down list of possible selections) and whether a resource is for an "international audience". In the absence of alternative formal vocabularies, following the ROS lead is a reasonable course of action.
The introduction of a controlled vocabulary for audience will be proposed for phase 2 of the RIOXX project, subject to funding.
rioxxterms:contributor Zero or more. Optional
This field is designed to describe an entity – for example the name of a person, organisation or service – responsible for making contributions to the content of the resource. As many rioxxterms:contributor elements may be entered as required. If the contributor is a person and it is desired to record that person's affiliation, the affiliation MUST be recorded as a separate rioxxterms:contributor element. This element SHOULD take an optional attribute called id, designed to hold a machine-readable and unique identifier, if available, for the contributor. Any ID entered here MUST be in a form which allows it to be parsed and recognised automatically. The ideal use of this element is to include both a machine-readable ID in the id attribute, and a text string in the body of the element, thus:
<rioxxterms:contributor id=”identifier-for-this-contributor-entity”>
    name-of-this-contributor-entity
</rioxxterms:contributor>
Where the contributor is a person, the RECOMMENDED format is to add text in the form Last Name, First Name(s), and to include an ORCID ID, if known, in its HTTP URI form, e.g.
<rioxxterms:contributor id=”http://orcid.org/0000-0002-1395-3092”>
    Lawson, Gerald
</rioxxterms:contributor>
 
dc:coverage Zero or more. Optional
This refers to the scope or extent of the content of the resource. It may include jurisdictional, temporal or spatial information. It is RECOMMENDED that, where possible, a recognised globally unique identifier is used, such as the Thesaurus of Geographic Names. For example, the place of publication may be recorded.
 
dc:type Zero or more. Optional
Type refers to the nature or genre of the content of the resource and can be entered as free text. Take care not to confuse this with dc:format.
The introduction of a controlled vocabulary for 'type' will be proposed for phase 2 of the RIOXX project, subject to funding.
dc.relation Zero or more. Optional
This format of this element SHOULD be an HTTP URI which points to a related resource. It is RECOMMENDED that, where available, the publisher’s DOI for the main resource being described in the RIOXX record also be entered here, in it’s HTTP form – e.g. http://dx.doi.org/10.1006/jmbi.1995.0238 Each related resource MUST appear as a separate instance of the field.
 
dcterms:references Zero or more. Optional
The format of this element SHOULD be an HTTP URI which points to a resource referenced by the resource described in the RIOXX record. Common examples might include a data-set which underpins a paper being described in the record. Each reference MUST appear as a separate instance of this element.
 
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.

Release Candidate 2 Released For Comment

Following further public consultation and discussion with stakeholders, we have just released RIOXX 2.0 Release Candidate 2 for comment.

The changes from RIOXX 2.0 Beta 1 are detailed in the release notes, but the most significant change is that we have added a recommendation to use ISNI identifiers for for organisations when named as authors, contributors or funders.

We think RIOXX 2.0 is very close to being ready for its final release and are aiming for a release date of 2015-01-09.

NISO's Access and License Indicators guidelines

RIOXX is required, following Jisc's V4OA process, to use two properties from the NISO's Access and License Indicators guidelines: 'license_ref' and 'free_to_read'. While the guidelines are still in a final review process, we have been assured that there will be no significant changes to these.

The 'license_ref' property is the most important of these - it's mandatory in a RIOXX record, while 'free_to_read' is optional.

The license_ref property

This property, which is mandatory for a RIOXX record requires an HTTP URI and a date, where the HTTP URI identifies a particular license. The ideal case is the use of one of the licenses which are acceptable to RCUK & HEFCE, such as http://creativecommons.org/licenses/by/4.0.

It is recognised that there will, however, be cases where either the license is not known, or where no appropriate HTTP URI has been established to identify the license. We did contemplate making 'license_ref' an optional property, but decided against this, on the grounds that this would undermine the drive towards clearer licensing of open access materials. Instead, we have taken steps which maintain the integrity of the mechanism supported by the use of the 'license_ref' property, while allowing repository managers to supply information in a valid RIOXX record.

The absence of a license means that the default copyright position of "All Rights Reserved" applies. For convenience, we have 'minted' the HTTP URI 'http://www.rioxx.net/licenses/all-rights-reserved' for such situations.

A particular, common case for repositories will be where an item is held in the repository under embargo. In such cases, the item is not licensed for use, and the default copyright position of "All Rights Reserved" applies. Again, for convenience, we have minted an HTTP URI, 'http://www.rioxx.net/licenses/under-embargo-all-rights-reserved', for embargoed items.

In neither of these cases are we creating some new license expression, but we are allowing the mechanism which requires explicit URIs to function, and are making the absence of a license explicit, rather than inferred.

Beyond this, the license entered here will be that demanded by the funder, the publisher or the owner of the repository (or even the author), depending on the circumstances (e.g. green/gold).

We welcome comment (please use the comments facility on this blog) on this, or on any aspect of RIOXX 2.0 RC 2.

*Edit: this post has been slightly edited to make clear that the recommendation to use ISNI to identify authors and contributors applies only where the author or contributor is an organisation rather than a person. ORCID remains the recommended identifier scheme for individual people.*

RIOXX 2.0 beta 1 released for comment

Update:

This consultation will be closed for comments at 17:00 BST on Wednesday 16th July

We are pleased to release a beta version of RIOXX 2.0 for public comment. RIOXX 2.0 has been developed by EDINA and Chygrove Ltd, with significant input from RCUK. This work is endorsed by RCUK and HEFCE and has been funded and facilitated by Jisc.

Background

RIOXX 1 was released in April 2013 to support institutional repositories in complying with open access reporting mandates from RCUK. Repository managers were facing a very short period of time in which to implement RIOXX. Consequently, RIOXX contained a number of compromises designed to minimise the amount of necessary software development and repository re-configuration.

Changes in the policy landscape have created a 'window of opportunity': we believe there is now sufficient time for the software development and repository reconfiguration necessary to implement a more complete version of RIOXX.

RIOXX 2.0

The RIOXX Team has worked closely with RCUK and HEFCE, to create a new version of the RIOXX application profile. Valid RIOXX 2.0 records are designed to satisfy the open access reporting requirements of RCUK and the REF 2020 reporting requirements of HEFCE. We expect RCUK to align its schedule for reporting with that of HEFCE. This means that repositories will have until April 2016 to reconfigure their repositories to support RIOXX 2.0, should they wish to use RIOXX to meet these funders' reporting requirements.

RIOXX 2.0 is specifically focussed on describing open access publications. It allows linking to other open access outputs types (such as research data sets for example), but does not describe these.

Vocabularies for Open Access (V4OA)

The RIOXX Team undertook to include the recommendations of the V4OA process. RIOXX 2.0 introduces several elements and vocabularies which have been recommended by V4OA.

Interoperability

The RIOXX Team is collaborating with OpenAIRE to ensure that there is a degree of interoperability with the OpenAIRE Guidelines For Literature Repositories (version 3.0). This interoperability is in one direction only: we undertake to ensure that a valid OpenAIRE 3.0 metadata record can be produced from a valid RIOXX 2.0 metadata record. We have invited OpenAIRE to verify interoperability and will be working closely with them in the next few weeks to test this.

Software (plugin) development and support

The RIOXX Team has had preliminary discussions with some repository system suppliers. Jisc plans to commission the development of plugins to support RIOXX 2.0 on the more popular repository platforms in use in the UK.

Jisc also plans to fund a repository support project which will have as part of its remit the support of repository managers in implementing RIOXX 2.0

Public review

RIOXX 2.0 (beta 1) is now available for public review. We anticipate making at least one further revision following your feedback - this can be offered either publicly in the comments on this blog post (preferred) or more privately to the rioxx admin email address: admin@rioxx.net (also OK).

We look forward to your comments!

Developing a RIOXX profile in CERIF

I have been working with Brigitte Jörg of the CERIF Support Project to consider how the RIOXX application profile might be expressed in CERIF. CERIF has become the de-facto standard for data exchange between Current Research Information Systems (CRIS), particularly in Europe. In the spirit of working as openly as possible, we are sharing our thinking about this as we go.

One particularly interesting aspect of this has how CERIF might handle the way in which we express cardinality constraints in the RIOXX profile (e.g. 'zero or one', 'one or more' etc.). This should have wider applicability, and might be an example of how the development of CERIF can be informed by solutions developed in other frameworks such as the Dublin Core (which underpins the current RIOXX application profile).

Brigitte has written up a commentary and a draft of how this might be done. Please do not consider this to be an official or supported CERIF expression of RIOXX.

RIOXX version 1.0 released

The RIOXX team are pleased to announce the release of version 1.0 of the RIOXX Guidelines and Application Profile.

To support the development of related software, an XML schema (XSD) has also been published

Please feel free to comment on any of this work by emailing the RIOXX team at admin@rioxx.net

RIOXX - minor updates to the application profile and a draft XSD schema

A minor update to the RIOXX application profile (v0.91) has been published, and a draft XSD schema intended for validation of RIOXX records has been made available. Comments on either or both are welcome.

These releases should be considered as 'release candidates'. Work is under way to develop plugins/patches for both ePrints and DSpace to help institutional repositories to implement the guidelines and application profile. The technical specifications for this work will also be made freely available for developers to implement support for other platforms. The final version (1.0) of the RIOXX application profile will be released when this development work is complete.

Please feel free to comment on any of this work by emailing the RIOXX team at admin@rioxx.net

RIOXX - Release candidate application profile and guidelines

We are pleased to announce that version 0.9 of the RIOXX guidelines and application profile are available for public comment:

These releases should be considered as 'release candidates'. Work is under way to commission plugins/patches for both ePrints and DSpace to help institutional repositories to implement the guidelines and application profile. The technical specifications for this work will also be made freely available for developers to implement support for other platforms.

Approaches to handling funders and projectIDs in a RIOXX record

The most important requirement for RIOXX is to provide a way to collect basic information about how research outputs (especially papers) have been funded. That is to say, we need to collect two types of information for a given paper:

  • the funder
  • the project or grant ID under which this research output was funded

RIOXX has at its heart a simple application profile of Dublin Core, the better to fit naturally with existing technical infrastructure and to be easily implemented. Following from this, it seems that there are the following possibilities for representing funder and projectID in a single record:

Funder and project id options

Option 1: Separate fields for Funder and ProjectID

This is the currently proposed approach. It has the virtue of introducing a very low barrier to data collection (the common repository interfaces support this) and provides for the primary use-case which is the collection of funding information about research outputs. In data-modelling terms, this is not a satisfying approach because it is not possible to relate a funder to a project ID within any given record. However:

  • it should be possible to build this relationship, if required, after the data has been harvested, using other correlating information (this is a trade-off for the requirement to implement this in existing platforms and workflows very soon)
  • the expression of this relationship is not a requirement in the usecase we are addressing

Option 2: Separate fields for Funder and ProjectID, ordering is significant

This is not a viable option as data transfer using XML does not reliably support the ordering of values within multi-value fields.

Option 3: Composite field for Funder and ProjectID

This is an obvious choice for an approach which does not depend on any extra external development (for example of a global unique ID system for projects/grants). However, this approach could be disruptive to the interfaces and workflows faced by repository managers, and we are aiming for minimal disruption to repository managers who are, after all, a key stake-holder. This option is still open for discussion and, indeed, we are discussing this with developers from the ePrints and DSpace communities.

Option 4: Syntactically rich string containing Funder and ProjectID components

This approach concatenates funder and projectID into one string, using an agreed delimiter character to separate them. This is the approach used in the OpenAIRE guidelines, and one which we have considered closely. We have decided to reject this approach because the projectIDs we will need to accommodate are unpredictable, and liable to contain whatever character we use to delimit this string. There are approaches to mitigating this issue - notably using encoding approaches such as URLEncoding - but this places an extra processing burden on suppliers and consumers with no guarantee that this will be implemented - this approach is therefore considered non-optimal and 'fragile'.

Option 5: Globally unique projectID

This is a more aspirational option - it cannot be implemented in the short-term because a system of globally uniques and persistent identifiers for grant-funded projects does not yet exist. However, in the medium-term this is feasible and is something we hope to explore in a later phase.

Next steps

We are now working with experts from the ePrints and DSpace communities to figure out what is viable in the short term. Our default position is to implement option 1. If we can implement option 3 without damaging the chances of the overall solution being adopted by repository managers on the common platforms, then this would be an attractive solution for the short term. For the longer term, we will continue to consider approaches to option 5 or, better still, a combination of option 5 and option 1, where the funders are also listed separately to the projectID (and actionable and persistent identifier which points to metadata about the funder), simply to avoid the need for multiple round-trip queries to, for example, list records with a given funder.

Comments on all/any aspects of this are welcome!

RIOXX version 0.8 available for public comment

We are please to announce that version 0.8 of the guidelines and application profile is available for public comment.

There is still some work to do, but we anticipate that the final version (1.0) will not depart from the current version significantly.

Please do comment on this version - it is quite likely that this will be the final public consultation before we publish version 1.0. You can comment either directly on the page or by emailing one of the project team.

Categories
Profiles
Tags
Topics