Your SlideShare is downloading. ×
0
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Rioxx 2 repository fringe
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rioxx 2 repository fringe

608

Published on

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

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

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
608
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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’
  • Transcript

    • 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

    ×