Governance Group minutes 2022-11-07

Monday 07 November 2022, 10:00

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

Minutes of last meeting

GM welcomed RGG members.

The previous minutes contained a number of actions assigned to GM pertaining to the finalisation of the Rioxx 'release candidate'. GM confirmed all actions had been performed, resulting in the successful publication of the release candidate.

Minutes of the last meeting were confirmed as accurate by meeting members. ND noted a typo in the initials of BJ's name within the minutes (typed as 'BV').

Action: GM to correct BJ's name initials in the minutes.

ISSUES: candidate release revisions – for discussion

Access rights specified at file level with dc:relation, e.g. using accessRightsURI attribute

GitHub issue: 47

GM provided a precis of the issue and opened discussion. A particular challenge highlighted in the GitHub issue with any introduction of the accessRightsURI attribute is the question of 'authority of assertion', since dc:relation is being used to communicate the existence of harvestable content but also more generic associative relations. Is it appropriate for access conditions to be specified for resources over which the local repository (or system) has zero control? PK indicated that re-scoping the use of dc:relation to only include those items over which local systems had control would have certain benefits for aggregators like CORE. BJ noted that such control can be difficult to define, even within local contexts, spanning different but related systems and teams. PW reiterated concerns about authority of assertion but noted, via his Notify research, that establishing associatve relations of all types is a growing requirment and therefore not one that Rioxx can avoid. PW highlighted the issue that Rioxx is seeking to go beyond dumb relations, as specified in the original conception of dc:relation by the DCMI, to refer to actionable resources. On this basis it was proposed that accessRightsURI should be included along with other Rioxx attributes, but that the absence of these attributes denoted a dumb relation. The schema documentation should be updated to reflect this distinction.
Action: GM to update schema documentation for dc:relation as described above and circulate to the RGG for refinement and therefter publication. This action is related to issue 46 below.

Semantics of 'resource' – need for tightening in the schema

GitHub issue: 46

Issue 46 was highlighted as being closely related to 47. GM introduced this issue for discussion.

It was noted that the originator of the issue (Angus Taggart, University of Sheffield) had correctly highlighted particular metadata modelling issues which had been introduced as a result of changes to v 2.0. The Rioxx move in v 3.0 to dc:relation as a mechanism for capturing harvestable resources, but also 'expressions' of works which are, can create contradictions in the metadata. GM reported that the issue also highlighted semantic drift in the schema documentation in the use of the word 'resource', a possible consequence of the incremental updaing of schema properties.

Action: GM and ME to review schema documentation to ensure consistency in the use of the word 'resource', as specified in the release candidate.

RGG members agreed to revisit the broader questions surrounding of associative relations and expressions, particularly in relation to the following properties: dc:format, rioxxterms:type, rioxxterms:version, and ali:licence_ref. It was noted that some of these were present as dc:relation attributes in a previous draft of Rioxx v 3.0 but had been jettisoned for simplicity reasons. RGG members agreed that an audit of current properties should be performed, together with an assessment of how they might be deployed in conjunction with dc:relation.

A general discussion emerged about the nature of associative scholarly relations and the concept of 'expressions' within scholarship.

Action: GM to perform preliminary audit as per above and circulate to RGG members for refinement and eventual publication. Action is related, and to be performed in conjunction, with the action arising from issue 47.

Should multiple URIs for the same 'thing' be represented?

GitHub issue: 44

This issue questions whether Rioxx should be enabling the encoding of multiple URIs as attributes when refining, say, rioxxterms:author. The schema documentation lists multiple PID systems that might be listed in a URI but does not indicate if or how multiple URIs might be communicated. Such a use case might arise if, for example, a repository wished to expose both an ORCID and an ISNI for the same author. In addition to rioxxterms:author, this question could be said to also arise in dc:publisher, dc:contributor, and to a lesser extent, rioxxterms:project and rioxxterms:grant. It is suggested in the GitHub issue that Rioxx could adopt an approach discussed within the DCMI, and proposed by PW when he was MD for DCMI, what uses white space to delineate URIs, as follows:

<rioxxterms:author uri="https://isni.org/isni/0000000419368139 https://ror.org/00n3w3b69"> University of Strathclyde </rioxxterms:author>

PW reported that the 'white space' approach was one he had overseen at DCMI but expressed concerns about Rioxx being optimised to satisfy the possible needs of downstream systems. PK recognised the issue raised but expressed caution that the manner of URI encoding was not strict XML and therefore a potentially an unsafe approach.

BV and PW reported their worry about the proliferation of PIDs within metadata schema, and their ability to create further ambiguity or contradiction; that futher proliferation should not be something Rioxx is promoting.

It was suggested that a possible compromise might be to state (in the schema documentation) that repositories wishing to express multiple PIDs may repeat them as necessary, instead of the 'white space' approach. In this proposal a rioxxterms:author, with both an ORCID and ISNI which a repository wished to expose, would be repeated as per:

<rioxxterms:author uri="https://isni.org/isni/0000000056397298"> Brian Cox </rioxxterms:author> <rioxxterms:author uri="https://orcid.org/equivalent-orcid-for-prof-brian-cox"> Brian Cox </rioxxterms:author>

PK indicated that this approach might be safer and certainly easier to parse, with de-duplication occurring as necessary. RGG members nevertheless agreed that it was an issue worth of revisitation at a later date.

Action: GM to update GitHub issue 44 accordingly.

CORE

PK announced to RGG members the recent decision by Jisc to suspend its funding of CORE. It was suggested by RGG members that the RGG could publish a blog post reaffirming the importance of aggregation services to repository discovery and in contributing to the scholarly commons, particularly as Rioxx has been optimised to promote superior harvesting.

Action: RGG to draft blog post for publication on Rioxx blog; GM to take first pass at a draft and circulate.

AOB

No other business was raised.

DONM

To be confirmed but agreed by members that it should be soon (ideally November or December).

GM 09/11/2022