Governance Group minutes 2020-06-17

Wednesday 17 June 2020, 15:00

Attendees: Petr Knoth (PK), Mick Eadie (ME), Paul Walk (PW), Nicola Dowson (ND), George Macgregor (GM - Chair),

Apologies: Kate O'Neill (KO)

Welcome

GM welcomed group members.

GM noted that the principal business of the present meeting was to finalise the RGG's discussion of outstanding GitHub issues, logged during the recent period of requirements and change proposal gathering.

Actions arising this meeting

Three actions were arising from the previous meeting.

Action: RGG members to reflect on labelling for above noted elements and agree via email on most appropriate label to use, e.g. work, object, resource, item, etc.. [in relation to issue #4]

GM reported on the outcome of email discussions and confirmed that the Group preference was for 'resource' to be used, e.g. rioxxterms:resource_deposit_date. Alternative labels were considered (e.g. work, item, document) but all either conflicted with other standards or had the potential to generate confusion. Agreement on this matter means that the change agreed in the previous meeting for issue #4 has been finalised.

Action: PW to liaise with Jochen Schirrwagen to discuss possible the RGG options for COAR integration within RIOXX. [in relation to issue #7]

PW reported that he had been in liaison with Kathleen Shearer, in her capacity as Executive Director of COAR, to discuss the COAR Controlled Vocabulary for Resource Type Genres V2.0. At time of writing the Vocabulary remains highly document centric. However, PW's discussions revealed that it is the intention of COAR to revisit the Vocabulary soon in order to take better account of research data requirements, but also consideration of practice-based or creative outputs. Given the development roadmap for the Vocabulary, PW was minded to confirm the RRG's previous decision to adopt the Vocabulary. He also noted that implementation of the vocabulary within repositories could be customised to reflect local requirements (e.g. a more limited term set) and that hierarchical browsing need not be implemented if there were concerns about users' attitudes to such a detailed vocabulary.

This finalises the discussion of issue #7.

Action: PK to send details to PW of how to access a RIOXX compliant metadata dump from CORE for analysis.

PW and PK confirmed that this action had taken place. PW intends to analyse the data in due course.

Minutes of last meeting

RGG members were satisfied with the minutes of 05/05/2020.

GitHub repository issues

Date of publication (#9)

GM summarised the nature of issue #9 in relation to rioxxterms:publication_date. A discussion ensued about whether it was necessary or appropriate for RIOXX to capture additional multiple dates on publication state, especially as acceptance date was already being captured (via dcterms:dateAccepted) and a role in REF compliance monitoring did not exist. Noting the role of rioxxterms:publication_date in providing a 'citable date' for resources described by RIOXX, it was agreed that it should remain unchanged within the profile.

PW and PK noted the relation this issue had to issue #6 (relating to ISO8601/W3CDTF encoding of dates) and how citable dates for publications assigned to seasonal issues of journals should be encoded. There was a discussion about the need to machine process this element.

GM confirmed that at a prior RGG meeting it was agreed seasonal issue dates would be mapped to specific months within the description / scope note associated with rioxxterms:publication_date. For example, a spring seasonal issue would be mapped to 2020-04; autumn to 2020-10, etc. This issue was discussed again in light of ISO8601/W3CDTF encoding for other dates within the profile and the 'decorative' nature of rioxxterms:publication_date as providing a 'citable' date for a described resource. It was ultimately agreed that no change was required in the encoding of element content but that additional guidance be provided on how to approach the capture of dates.

No substantive change agreed. rioxxterms:publication_date remains but with further examples of suggested date content to be included in element scope notes / description.

Include field for DOI (#10)

Issue #10 was originally raised by John Salter (Leeds) and proposed the creation of a new DOI element, in addition to dcterms:identifier (designed within RIOXX to capture the location of the deposited repository resource) and rioxxterms:version_of_record (designed to refer to officially published manifestation of the resource, normally via DOI).

Discussion centred on whether such an element was required, given that rioxxterms:version_of_record is designed to accommodate an HTTP URI to a persistent identifier. GM explained that the motivation behind such an element was to reduce the processing overhead of aggregators when parsing and validating identifiers. PK reported that the addition of such an element would make little material difference to how services such as CORE harvested and interpreted this data. It may reduce technical overhead slightly but identifiers such as DOIs can be identified as such during parsing, owing to their standardised syntax. The RGG therefore decided to pass over this change proposal in this instance.

The accommodation of alternative identifiers was raised by PK, such as PMIDs, URNs, etc. which prompted a wider discussion about identifiers. PW noted that PMIDs did not typically identify versions of record and should therefore not be considered in scope of this element. GM suggested that greater specificity could be achieved in version_of_record by introducing an element refinement denoting which persistent identifier was being used. This would enable the accommodation of a wider variety of idenitifiers. PW questioned whether this was necessary since in most cases the identifier would be a DOI and maintenance of such a refinement list could be problematic. After consideration it was agreed that developments in such identifiers should be monitored for possible future incorporation into RIOXX.

No change agreed.

RIOXX for theses (#11)

Issue #11 was recorded by KO on behalf of a UKCORR member. It was a speculative request for the RGG to consider whether "fields like supervisor, degree type, etc." being included within RIOXX and in what capacity RIOXX should be considered suitable for thesis description. PW noted that in the early days of drafting RIOXX the description of theses was considered but was concluded to be outside its scope.

GM highlighted the UKETD_DC as the standard for thesis description and harvesting by the British Library's EThOS service. He reported that all major repository platforms supported UKETD_DC, with EPrints and DSpace supporting recent UKETD changes in order to capture ORCID, among other things. PW therefore suggested that RIOXX should no longer revisit the issue of thesis description since a superior extant schema was available and that RIOXX was never conceptualised to describe theses.

No change agreed.

GM confirmed all outstanding issues on the RIOXX GitHub repository had now been discussed and decisions taken. GM reported that he would collate all agreed changes and circulate to RGG members, thus enabling drafting of a revised profile and the closing of issues within the GitHub repository.

• Action: GM to collate agreed profile changes for circulation and review of RGG members, and for PW to update the RIOXX GitHub repository.

AOB

GM drew the meeting to a close.

No other business was raised by members.

DONM

To be confirmed after the action above has been completed and discussed over email.

GM 23/06/2020