Original concerns for RIOXX:

• 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 identifiers pointing to related data sets
  • How to represent the terms of use for an item

Original principles:

• Purpose driven – Focussed on satisfying RCUK reporting requirements
• Simple (re-use DC, not CERIF)
• Generic in scope (don’t tie down to specific types o output)
• Interoperable – specifically with OpenAIRE
• Developed openly – public consultation

Has anything changed with RIOXX 2 (mid-2014)?

• Still purpose driven, but no encompassing HEFCE requirements as well
• Slightly more sophisticated / complex but still quite simple
• No longer ‘generic’ – explicit focus on publications
• No longer seen as a temporary measure – positioned to support REF2020
• Interoperability still key – and currently working on an OpenAIRE crosswalk

Other changes:

• Implementing recommendations from the V4OA process
  • controlled vocabs for rioxxterms:version, rioxxterms:apc
  • Use of NISO’s Open Access Metadata and Indicators (licence_ref)

Current status:

• version 2.0 beta was released for public consultation in June 2014
• version 2.0 RC 1 has been compiled
• accompanying guidelines are being written
• XSD schema beeen developed
• expect full release in late August/early September

Some specific elements:

• 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
  • dc:identifier MUST be an HTTP URI
• dc:relation and rioxxterms:version_of_record
  • rioxxterms:version_of_record is an HTTP URI which is a persistent identifier for the published version of a resource
  • will often be the HTTP URI form of a DOI
• dc:relation
  • option property pointing to other material (e.g. dataset)
• dcterms:dateAccepted
  • MUST be provided
  • more precise than other dated events (‘published’ date very grey area)
• rioxxterms:author & rioxxterms:contributor
  • MUST be HTTP URIs – ORCID strongly recommended
  • one rioxxterms:author per author
  • rioxxterms:contributor is for parties that are not authors but credited with some contribution to publication
• rioxxterms:project
  • joins funder and projected in one, slightly more complex, proerty
  • The use of funder IDs (DOIs in their HTTP URI form) from FundRef is recommended, but other ID schemes can be used and name can be used
• license_ref
  • adopted from NISO’s Open Access Metadata and Indicators
  • takes an HTTP URI and a start date
  • URI should identify a license
    • there is work under way to create a ‘white list’ of acceptable licenses
  • embargoes can be expressed by using the ‘start date’ to show the date on which the license takes effect

Funding of development of RIOXX as application profile now at an end, but funding for further developments (e.g. s/w development for repositories etc.)

RIOXX is endorsed by both RCUK and HEFCE

Q: What about implementing RIOXX in CRIS systems?

A: Some work on mapping between CERIF and RIOXX, although not ongoing work. Technical description available for any one to implement.

A (Balviar): In terms of developing plugins for commercial products – not talked to commercial suppliers yet, but planning to look at what can be developed and conversations now starting.

A (James): Already got RIOXX terms in Pure feed at Edinburgh

Q: Can you clarify ‘first name author’ vs ‘corresponding author’ – do you intend the first named author to be the corresponding author?

A: Understand that the ‘common case’ is that the first name author is the corresponding author [at this point lots of disagreement from the floor on this point].

‘first name author’ seen as synonym for ‘lead author’

Q: Why is vocabulary for (?) not in line with REF vocabulary

A: HEFCE accepts wider range of outputs that ‘publications’, but RIOXX specifically focusses on publications  – where most OA issues lie

Q: ‘Date accepted’ what about historic publications? Won’t have date of acceptance

A: RIOXX not designed for retrospective publication – going forward only. Not a general purpose bibliographic record

Comment from Peter Burnhill: RIOXX is not a cataloguing schema – it is a set of labels

Paul W emphasises – RIOXX is not a ‘record’ format – the systems outputting RIOXX will have much richer metadata already. There is no point in ‘subverting’ RIOXX for historical purposes – this isn’t its intended purpose.

Q: Can an author have multiple IDs in RIOXX

A: Not at the moment. Mapping between IDs for authors is a different problem space, not one that RIOXX tries to address

Comment from RCUK: Biggest problem is monitoring compliance with our policies – which RIOXX will help with a lot

Comments from floor: starting to see institutions issues ORCIDs for their researchers – could see multiple ORCIDs from a single person. Similarly with DOIs – upload a publishers PDF to Figshare you get a new DOI

Q: If you are producing RIOXX what about OpenAIRE

A: There is nothing in RIOXX that would stop it being OpenAIRE compliant – so RIOXX records can be transformed into OpenAIRE records (but no vice versa)