Overview of RIOXX 2.0 given to Repository Fringe event, Edinburgh, 2014-07-30

1. Paul Walk
p.walk@ed.ac.uk
@paulwalk
http://www.paulwalk.net
The RIOXX 2.0 metadata application profile

2. recap: what is RIOXX?
• a metadata ‘application profile’ intended to allow repositories to report on
open access publications in a way which satisfies reporting requirements from
RCUK and HEFCE
• a set of guidelines for repository implementation
• an XSD schema to facilitate metadata validation
• a supporting website (http://www.rioxx.net)
• born at UKOLN
• developed by EDINA and Chygrove Ltd.
• development closely supported by RCUK & HEFCE and funded by Jisc

3. the RIOXX team
• Paul Walk (EDINA)
• Sheridan Brown (Chygrove Ltd)
• Ian Stuart (EDINA)
with considerable support from:
• Ben Ryan (RCUK)
• Ben Johnson (HEFCE)

4. recap: original concerns
• primary:
• how to represent the funder
• how to represent the project/grant
• secondary:
• how to represent the persistent identifier of the item described
• provisions of identifier(s) pointing to related dataset(s)
• how to represent the rights of use of the item described

5. recap: original principles (early 2013)
• purpose driven
• focussed on satisfying RCUK reporting requirements
• simple - has to be relatively easy to implement
• ‘shallow’ structure, re-use of Dublin Core where possible (not CERIF!)
• generic in scope
• avoid specificity where possible - consider other output types (e.g. data)
• transient
• was conceived as an interim solution, likely to be superseded by a CERIF-
based approach
• interoperable
• where possible, respect and support related efforts - notably OpenAIRE
• developed openly
• public consultation

6. what’s changed (mid 2014)?
• purpose driven ✔
• now also serves HEFCE requirements, without deviation from original remit
• simple ✔
• slightly more sophisticated - from an entirely ‘flat’ model to a ‘shallow’ one
• generic in scope ✘
• now an explicit focus on publications
• transient ✘
• being positioned to support REF 2020, so likely to be around for a while!
• interoperable ✔
• we are working closely with OpenAIRE to develop a crosswalk
• developed openly ✔
• http://www.paulwalk.net/2012/10/23/rioxx-application-profile-draft-1/
• http://www.rioxx.net/2014/06/27/rioxx-2-0-beta-1-released-for-comment/

7. what else has changed (mid 2014)?
• implementing recommendations from the V4OA process:
• controlled vocabularies for rioxxterms:version, rioxxterms:apc
• use of NISO’s Open Access Metadata and Indicators (license_ref and
free_to_read)
• a more expressive property for ‘funder’ and ‘project_id’
• stricter requirements in some properties

8. current status
• version 2.0 beta 1 was released for public consultation in June 2014
• good response - thank you!
• version 2.0 RC 1 has been compiled following this
• the accompanying guidelines are being written
• an XSD schema has been developed
• we are waiting for NISO’s Open Access Metadata and Indicators to be
released
• expect the full release of RIOXX 2.0 in late August / early September
• funding for RIOXX 2.0 has now finished
• there will be funding for repository plugin development

9. some specific elements
• dc:identifier
• dc:relation & rioxxterms:version_of_record
• dcterms:dateAccepted
• rioxxterms:author & rioxxterms:contributor
• rioxxterms:project
• license_ref

10. dc:identifier
• identifies the open access item being described by the RIOXX metadata
record.
• regardless of where it is
• recommended to identify the resource itself, not a ‘splash page’
• this will not always be possible or desirable
• whatever it identifies, it MUST be an HTTP URI
• (‘HTTP URI’ is posh for a ‘URL’)

11. dc:relation & rioxxterms:version_of_record
• rioxxterms:version_of_record
• an HTTP URI which is a persistent identifier for the published version of the
resource
• will often (normally?) be a DOI
• dc:relation
• optional property containing an HTTP URI identifying related resources (e.g.
research data sets. software source code etc.)

12. dcterms:dateAccepted
• this MUST be provided
• is more precise than other possible dated events - such as ‘published’

13. rioxxterms:author & rioxxterms:contributor
• both of these accept an optional ‘ID’ attribute
• this MUST be an HTTP URI
• use of ORCID is strongly recommended
• all authors should be represented as individual rioxxterms:author properties
• the ‘first named author’ can be indicated with another optional attribute called,
er…, ‘first-named-author’
• rioxxterms:contributor is for other parties that are not authors but are credited
with contributing in some way to the publication

14. rioxxterms:project
• this now joins funder and project_id in one, slightly more complex, property
• the use of funder IDs (DOIs in their HTTP URI form) from FundRef is
recommended

15. license_ref
• adopted from NISO’s Open Access Metadata and Indicators
• takes an HTTP URI and a start date
• the URI should identify a license
• there is work under way to create a ‘white list’ of acceptable licenses
• embargoes can be expressed this way, with a license identified to ‘take effect’
at some (possibly) future date

16. summary
• application profile and supporting XML schema are very near to release
• the application profile currently on the website (RIOXX 2.0 beta 1) is very
unlikely to change in any significant way
• detailed guidelines for implementation are being drafted right now
• work is under way to develop a ‘white list’ of acceptable licenses
• Jisc will be funding work to develop plugins
• RIOXX is endorsed by both RCUK and HEFCE

17. Paul Walk
p.walk@ed.ac.uk
@paulwalk
http://www.paulwalk.net
thank you for listening!
http://www.rioxx.net