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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • special thanks to Ben Ryan at RCUK with whom we have worked closely on this in recent months and who is just the sort of client one wants for this kind of work. Ben is in the room, and we also have Ben Johnson from HEFCE who has also been supportive.
  • these have not changed
  • purpose driven - the whole point of the ‘application profile’
  • CERIF expressions of the RIOXX model are possible
  • all of this has been done in the understanding that there will be a longer period available for implementation
  • 2.0 RC 1 has not been released as the changes from version 2.0 beta 1 are minimal.
  • acceptance date represents a more clearly identifiable ‘business event’
  • 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!