Linking of recommendations to EOSC readiness

[servansod]

Origin: Review Report PMOC-857641-1-RP1

Recommendation 4 (Linking of Recommendations to EOSC Readiness): WP2 has developed 30 recommendations for integrating PaN facilities and data services to EOSC. In the second reporting period, these recommendations must be structured and prioritized based on their relative importance for EOSC readiness. Specifically, the recommendations must be segmented to categories like mandatory & must-have, optional and nice to have etc. and serve as a basis for defining EOSC maturity levels. This work should enable PaN facilities and data services providers to focus on the implementation of the recommendations that matter the most for their successful integration with EOSC.

Impacted document: https://doi.org/10.5281/zenodo.4014811

[wiggle120]

this was the recommendation that I had concerns with but that Brian did not. As such, he is probably better placed as the 'assignee' of this issue. He is also the one who will be writing the actual revised data policy framework as part of D2.3. Thanks! My main concern with this recommendation is that our 30 element framework is not '30 recommendations for integrating PaN facilities and data services to EOSC' - rather, it is a framework of 30 elements that should inform a PaN data policy. This is not the same thing!

[wiggle120]

Raised this again with Brian at the last monthly WP2 meeting. He and other colleagues at the meeting agreed that this recommendation needs clarification. Brian to raise at next PEB.

[RKrahl]

Just a comment: I have not been involved in the review process, so there is a fair chance that I got that entirely wrong. But I was involved in the policy consultations and this recomendation seem to be really weird in my eyes. The idea behind the “Thirty Elements to Consider within a PaN Data Policy Framework” was that they should serve as a basis for the discussion during the policy consultations. It were – as the title suggests – things to consider, not more. They were by no means intended to be taken as an indicator for EOSC readiness. We have ExPaNDS partners that decided after careful consideration not to adopt some or even most of these elements in their policy. But that doesn't mean that they would not be EOSC mature.

[wiggle120]

Yes, exactly so - I agree 100%. Either this recommendation is meant to refer to the metadata framework, i.e. D2.2 (it might just about make sense in relation to that), or the reviewers seem to have misunderstood somehow the purpose of the data policy framework in quite a major way.

[brianmatthews42]

How about for a response text:

We are unclear on which activity within WP2 this refers to. The second data policy deliverable D2.3 is close to final preparation and it would not be appropriate to make such a categorisation in this document; partner RIs gave feedback that this would not be an appropriate approach. D2.2 already categorised metadata recommendations, and we would take this further in proposing FAIR readiness metrics in D2.6 and in D2.7, taking into account recommendations for integration in the EOSC.

[wiggle120]

Yes, to me, this makes much more sense!

[servansod]

Thanks @brianmatthews42. Could we add in the response text a few arguments as to why it would not be appropriate to categorise the data policy framework elements as suggested? Looking at the 30 elements with an external eye, you could well imagine the categorisation suggested makes sense. For example elements number 16 and 17 seem like "must-haves" for EOSC whereas element 26 would be more optional. We have to explain a bit why it is not so easy / appropriate. I admit I haven't understood myself yet.

[RKrahl]

The “Thirty Elements to Consider within a PaN Data Policy Framework” contain a lot of useful suggestions for things that should be done in the practice. But there has been some discussion about what the purpose of a data policy is. There are ExPaNDS partners (including HZB) that argue that most suggestions in the thirty elements are technical details that do not belong into a policy. That it is even harmful to have that level of detail there, because it will have the effect to setting things in stone that cannot easily changed or adapted afterwards. This will in the end prevent innovation and obstruct the provision of best services to the users and the scientific community.

[spc93]

Perhaps we need a working definition of what ‘policy’ means. Wikipedia describes different kinds. It seems that our individual interpretations are all correct but different.

From: Rolf Krahl @.> Sent: 21 July 2021 10:55 To: ExPaNDS-eu/ExPaNDS @.> Cc: Subscribed @.***> Subject: Re: [ExPaNDS-eu/ExPaNDS] Structure and prioritise the 30 data policy framework elements wrt EOSC readiness (#19)

The “Thirty Elements to Consider within a PaN Data Policy Framework” contain a lot of useful suggestions for things that should be done in the practice. But there has been some discussion about what the purpose of a data policy is. There are ExPaNDS partners (including HZB) that argue that most suggestions in the thirty elements are technical details that do not belong into a policy. That it is even harmful to have that level of detail there, because will have the effect to setting things in stone that cannot easily changed or adapted afterwards. This will in the end prevent innovation and obstruct the provision of best services to the users and the scientific community.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ExPaNDS-eu/ExPaNDS/issues/19#issuecomment-884056745, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADGIGMHDF2XVFGSUL4D6Q2LTY2KPBANCNFSM5AATOGSQ.

-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

[RKrahl]

The problem is that there are certain things that we need to be regulated in a legally binding form. @servansod mentioned for instance element 17 (the licence under which the data are made available), this is indeed crucial, because that is not something that the facility could determine on its own, we need a legally binding statement from the user about that. Other things are GDPR issues: we need to base our research data management on a contract with the user, otherwise we would not be allowed to process the user's personal data. That is why our data policy becomes part of the contract that the user concludes with our facility. But then, of course, we need to be careful about what we write into that contract and what we prefer to leave open.

[UweKonrad]

But what does consider mean? It does not mean that those suggestions have to be included, only to be thought of (may need help from native English speakers)!

[wiggle120]

Yes, indeed - that is why 'consider' is in the title (just made an edit to my post: I suggested 'consider' in the context of something elsewhere! But that is not what we are talking about here.). The 30 element framework aims to present elements that ExPaNDS partners need to (consider) and make choices about. Therefore, it follows that a valid choice would be not to include a particular element in their data policy.

[wiggle120]

Further to this, I really wish I could share the write up of D2.3 with you now, as it gives a much better sense of the diversity that exists when it comes to views and needs across ExPaNDS partners, but Brian is currently writing his sections now and it is better to have the entire picture. Hopefully, the draft will go to internal review soon... there have already been several occasions where colleagues have asked about the consultation feedback and what we can learn from that.

[servansod]

To summarise separate thread between Patrick, Abigail and Brian: it was agreed to apply this recommendation to the work related to D2.6 "Self-evaluation Photon and Neutron RIs for FAIR data certification" that will be starting soon.

[brianmatthews42]

Recommend to close this issue

[twdragon]

@servansod Closing, you can reopen it if needed

[marauskajul]

D2.6 is not yet submitted, we want to make sure that this is really covered.

[wiggle120]

I'm not sure about this - Brian will need to comment. Thanks.

[wiggle120]

Looking at the first comment above (i.e. that includes the recommendation), the document linked there is to the data policy deliverable. We completed the final version of this last August. I think that may be why this issue was closed by Sophie? To me, this does not link to the work we are doing in D2.6, which is around FAIR evaluation, not data policy.

[servansod]

Oh, we need to discuss this issue very quickly then. Juliane is right, it was intended to be addressed in D2.6. Will come back to you ASAP @wiggle120 and @brianmatthews42.

[servansod]

Final justification for this recommendation (taken from the periodic report):

Following the consultation on the data policy framework which was carried out around the time of our mid-term review, the 30 elements to inform a PaN data policy were reduced to 21. Although these, once implemented, do participate in making a facility FAIRer and thus satisfy the EOSC readiness w.r.t. the Rule of Participation that EOSC resources align with FAIR Principles, we couldn’t evaluate the relative importance of each element in that regard. All of these elements have to be considered by the facilities, which, then, can make a choice to adopt them in their data policy or not. During the second period of ExPaNDS, a FAIR self-assessment was conducted with each partner facility. The questions used for this exercise derive from a systematic analysis of the FAIR principles and existing FAIR assessment models, including CoreTrustSeal + FAIRenabling and the RDA FAIR data maturity indicators. The self-assessment was found to be a useful and valuable exercise for understanding current levels of FAIRness at our facilities and for articulating the current and planned implementations to support FAIR in the future, and thus readiness for the EOSC. The EOSC readiness of PaN RIs data catalogues was otherwise monitored in the frame of WP3, as defined in the roadmap and the following KPI monitoring (see section 1.2.3. task 3.5). Same is true for WP4, see section 1.2.4 task 4.7.