Wednesday 06 May 2020, 13:00
Attendees: Petr Knoth (PK), Mick Eadie (ME), Paul Walk (PW), Nicola Dowson (ND), George Macgregor (GM - Chair), Kate O'Neill (KO)
GM welcomed group members. No apologies; all present.
GM noted that the principal business of the present meeting was to continue RGG discussion of outstanding GitHub issues, logged during the recent period of requirements and change proposal gathering.
Three actions were arising from the previous meeting.
Action: GM to liaise with ADC HEI contacts regarding RGG position and offer support.
Nicola Siminson from Glasgow School of Art has been invited (by ND) to attend the next UKCORR Committee meeting to discuss issues surrounding the description of creative and practitioner works in repositories more generally. Issues raised at the previous RGG meeting will be raised and discussed.
Action: RGG members encouraged to meditate on these proposals and return to the next meeting prepared to modify the proposals and/or agree or reject.
This action was incorporated into the business of the present meeting. (see subsequent sections of minutes)
Action: ND to circulate details of REF2021 classification of seasonal dates for incorporation into publication_date
.
ND reported to group members by email that a REF2021 classification of seasonal dates could not be found. Any season classification of dates to support publication_date
will therefore need devising by the RGG.
RGG members were satisfied with the minutes of 30/03/2020.
rioxxterms:fulltext_deposit_date
& Add rioxxterms:record_public_release_date
(#4 & #5)Issues #4 and #5 were considered together at the previous meeting. Owing to evolving thinking by RGG members at the 30-03-2020 meeting, a decision on how this should be implemented was deferred. RGG members were actioned to reflect on possible solutions. GM provided a brief recap of the motivation behind these new, additional elements.
GM reported that he had considered extant practice in relation to the capture, exposure and definition of deposit dates. He noted that the distinction between full-text deposit and full-text exposure was modelled in both the REF CC plugin for EPrints and the REF compliance checker for DSpace, both of which make the distinction between with first compliant deposit (FCD) and first compliant Open Access (FOA). The distinction is principally made for compliance checking purposes but also to record when full-text becomes discoverable in instances where 'dark archived' deposits may have taken place.
On this basis GM proposed the creation of an additional element to accompany rioxxterms:fulltext_deposit_date
and rioxxterms:record_public_release_date
: rioxxterms:fulltext_exposed_date
. Each would need to be precisely defined. These definitions would be cognate with FCD and FOA allowing reuse in other applications or vice versa. Inclusion of the additional element would address issues raised at the previous meeting and satisfy most use cases, including those stated by PK and CORE. After a frank discussion RGG members agreed to this approach.
PW queried the labelling of the elements, suggesting that 'fulltext' may be too specific given the diversity of content which RIOXX may be used to describe. PW noted that 'item' may seem appropriate but in other repository platforms it can have different definitions. 'Work' was therefore proposed by PW as an alternative. PK suggested 'resource' as a more accommodating alternative but GM expressed worry about the definition of 'resource' within a web standards context, e.g. URI, URN, URL, in which the term 'resource' is extremely elastic. 'Object' was suggested as an alternative.
RGG agreed that 'fulltext' was inappropriate an alternative should be found.
Change agreed -- pending confirmation of element labelling.
Issue #7 was originally raised by Bram Luyten at Atmire and was motivated by a need for greater alignment between RIOXX and COAR vocabulary, the latter of which is used within OpenAIRE v.4. Bram indicated that the existing simplicity of rioxxterms:type
was something he valued in preference of the more exhaustive COAR vocabulary but noted the need to arrive at some alignment.
RGG members discussed the merits of updating the existing rioxxterms:type
controlled list, imposing mappings between type
and the COAR vocabulary, and updating type
to use only the COAR vocabulary. GM intimated that the COAR vocabulary, while a welcome step towards a standardized type description, offered unnecessary levels of specificity given the intended application of RIOXX. PW suggested that one possible solution might be for RIOXX to move to the COAR vocabulary but stipulate the use of values occupying higher levels of the vocabulary hierarchy. This would entail the use of the superordinate, for example, conference object as standard within type instead of the numerous subordinate values available, such as conference proceedings, conference paper, conference poster, conference paper not in proceedings, conference poster not in proceedings. This would obviate the negative aspects of such a rich vocabulary within the context of RIOXX but enable adoption of the COAR vocabulary, thereby affording interoperability without the need for mappings or adjustments to the existing type
values.
A brief discussion about existing usage of the rioxxterms:type
element ensued. A better understanding of how repositories were making use of type
would aid decision making on this matter, opined PW. PW also noted his existing communication channels with Jochen Schirrwagen (a principal author of the COAR Controlled Vocabulary for Resource Type Genres) as an opportunity to discuss the current usage of the vocabulary, future amendments and RGG thinking.
Action: PW to liaise with Jochen Schirrwagen to discuss possible the RGG options for COAR integration within RIOXX.
Action: PK to send details to PW of how to access a RIOXX compliant metadata dump from CORE for analysis.
Change agreed in principle -- RGG members agreed that the values of rioxxterms:type would need to change to take account of the COAR Controlled Vocabulary for Resource Type Genres. The exact approach to this change pending PW's discussions with Jochen Schirrwagen.
During the issue #7 deliberations a frank discussion arose among RGG members on the topic of RIOXX's advocacy. PW reported that advocating previous iterations of RIOXX was arduous and often yielded little meaningful engagement of community members. There was agreement that aggressive advocacy was not the objective in this instance and that RIOXX should be communicated to the community as an opportunity to observe good practice, solve a number of harvesting issues, and support the delivery of improved repository infrastructure; for example improved reporting via aggregation dashboards provided by services such as CORE. PK noted that the latter consideration made a good carrot for better CORE participation, which in turn would be promoted by CORE as a reason why repositories should adopt RIOXX v.3.
rioxxterms:version
values (#8)Concerns surrounding rioxxterms:version
values were expressed on the GitHub repository by GM on behalf of a UKCORR member. These concerns centred on the use of the NISO Journal Article Versions (JAV) vocabulary and its perceived lack of use within scholarly publishing circles. JAV was noted as being integrated within OpenAIRE v.4 for literature repositories.
After deliberation is was agreed that JAV should continue to be used for version
because no superior alternative existed and the creation of a new vocabulary would do nothing to support interoperability. The status of JAV would need to be monitored as there was general agreement that
No change agreed.
GM drew the meeting to a close owing to pressures of time and suggested a follow-up meeting be organized in coming weeks.
No other business was raised by members.
The exact date/time is to be confirmed but is expected to be within the next couple of weeks.
GM 12/05/2020