Monday 31 March 2020, 14: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 and thanked them for attending the meeting in light of turmoil surrounding the Covid-19 outbreak.
There were no actions arising from this meeting owing to recent attempts to solicit requirements and change proposals from the community.
RGG members were satisfied with the minutes of 29/10/2019.
GM opened the meeting and noted the principal business was to discuss and agree the proposed changes documented at the RIOXX GitHub repository and arising from several months of community engagement.
GM noted that one of the more significant events to report was the engagement of HEIs operating within the arts, design and creative disciplines (ADC). GM reported that these institutions felt poorly served by extant metadata schema and viewed the recent RIOXX community engagement effort as an opportunity to address this deficit. GM noted poor alignment between ADC content and metadata were particularly acute in areas such as
rioxxterms:version, but were also an issue elsewhere. Such issues were present in profiles other than RIOXX too. GM indicated the GitHub repository had been updated to include proposed changes to better suit ADC content but that it was necessary to consider to what extent RIOXX could address the issues properly.
PW provided background on the purpose motivating the creation of RIOXX. PW noted that the functional scope of RIOXX had been to accommodate academic outputs of a textual nature only, principally articles and conference papers, partly as a consequence of the then RCUK Open Access Policy. PW questioned whether it would be possible to accommodate ADC requirements within RIOXX easily without re-engineering the profile and whether it was sensible to turn RIOXX into a general scheme when alternatives are available.
GM acknowledged that in key areas, such as
dcterms:creator, no suitable or stable controlled vocabularies were available to accommodate ADC content satisfactorily, making it difficult for ADC content to be better modelled in RIOXX.
ME and PK commented that it might make sense to expand the functional scope to REF-able outputs. Members discussed this suggestion at length but concluded that similar issues would arise with non-standard content, including ADC content, since relevant vocabularies would remain lacking.
PW expressed worry that RGG attempts to accommodate ADC content would fail without lengthy involvement from ADC communities and that it would instead be more sensible to approve changes, many of which were straightforward, within the current functional scope. RGG members agreed this as being the way to proceed for the time being.
GM reported that we would liaise with his ADC contacts to relay RGG concerns, with a view to supporting or facilitating the ADC community in pushing forward on appropriate standards to support ADC content, to either potentially create the foundation for a dedicated metadata profile or improved opportunities for embedding with RIOXX at some future date.
GM referred to the RIOXX GitHub repository and suggested the RGG work through each to agree changes but noted that the large number change proposals may demand a follow-up meeting.
GM noted that he had posted this particular issue (#12), both within the context of the inadequacy of 'author' within ADC content but also against the background of growing interest in CRediT (Contributor Roles Taxonomy). It was reported that repositories are increasingly capturing CRediT data and some publishers were beginning to publish this data alongside articles as standard (e.g. PLOS, MDPI). ME confirmed that the University of Glasgow had been capturing CRediT data within Enlighten.
GM questioned whether it might be appropriate to consider moving to dcterms:creator while using the CRediT values as element refinements. GM also noted, however, that CRediT did little to address ADC content since its values were primarily focused on traditional scholarship. PW reported that -- in his capacity as DCMI director -- that discussion
After some discussion it was agreed that while this proposal was of merit, take up of CRediT remained too small to justify a change to RIOXX at this time. Take-up of CRediT would of course be monitored as would changes arising from DCMI activities.
No change was agreed. rioxxterms:author remains in its current form.
RGG members agreed that this issue (#1) was a simple change to make.
PW noted the convention that HTTP and HTTPS were essentially cognate, but that it made sense to be explicit about this in the profile scope notes. KO noted that the reported issue stemmed from how HTTPS URIs were being treated by software which had implemented RIOXX. Purist implementations of the profile were such that some repository software was permitting only HTTP URIs instead of both HTTP and HTTPS.
RGG members agreed change for issue (#3) since
free_to_read was inconsistently applied across the sector, its definition was unclear and its inclusion was causing an internal inconsistency in RIOXX (i.e. contracting and in some instances duplicating the
rioxxterms:record_public_release_date(#4 & #5)
PK recapitulated the motivation for opening issues #4 and #5, including superior monitoring of open access content growth and potential REF applications for services such as CORE. There was general agreement that capturing this data were useful and appropriate, and could be easily captured at a systems level.
In relation to
fulltext_deposit_date a detailed discussion surrounding the distinction between 'deposit' and 'exposure' ensued and the danger of conflating the two. The intersection of UK REF OA requirements for 'deposit' and 'access' were noted by members as complicating the interpretation of such a proposed element and its accurate capture. KO noted that deposits are often initially made dark owing to local systems and processes. To this extent a deposit can be made but may not necessarily be exposed, i.e. open for discovery and access. Discussions continued about the scope and definition of fulltext_deposit_date (e.g. fulltext exposure? fulltext access?) and the potential significance
Since thinking on this proposed change was evolving, GM suggested that the RGG reflect on the discussion and aim to make a decision about issues #4 and #5 at the next RGG meeting.
rioxxterms:publication_dateto be encoded as ISO 8601 (post–2004 versions) (#6)
The background to issue #6 was outlined by PK. PW noted that it was often the case that publishers did not provide reliable publication dates, hence the why ISO8601 encoded dates were not mandatory in RIOXX v1 or v2. There were also problems arising from publishers assigning articles to seasonal issues (e.g. spring, winter, etc.) which could not be expressed as an ISO8601 date easily.
Tightening the content of
publication_date as per the proposal in #6 was deemed sensible by the RGG. This would enable publication dates of varying granularity to be expressed as an ISO8601 compliant date irrespective of whether day or month was available. PW suggested that scoping the element as per GM's comments in the GitHub issue would enable seasonal issue dates to be expressed in ISO8601 accurately. ND reported that some standardization in this regard had been introduced by the UK REF2021 OA Policy and that it would be wise to follow this convention.
Change agreed -- but pending confirmation of REF2021 classifications.
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.