Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rioxx 2 repository fringe


Published on

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

Published in: Education
  • Be the first to comment

  • Be the first to like this

Rioxx 2 repository fringe

  1. 1. Paul Walk @paulwalk The RIOXX 2.0 metadata application profile
  2. 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 ( • born at UKOLN • developed by EDINA and Chygrove Ltd. • development closely supported by RCUK & HEFCE and funded by Jisc
  3. 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. 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. 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. 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 ✔ • •
  7. 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. 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. 9. some specific elements • dc:identifier • dc:relation & rioxxterms:version_of_record • dcterms:dateAccepted • rioxxterms:author & rioxxterms:contributor • rioxxterms:project • license_ref
  10. 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. 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. 12. dcterms:dateAccepted • this MUST be provided • is more precise than other possible dated events - such as ‘published’
  13. 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. 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. 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. 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. 17. Paul Walk @paulwalk thank you for listening!