Skip to main content

Notice

We are in the process of rolling out a soft launch of the RDA website, which includes a new member platform. Existing RDA members PLEASE REACTIVATE YOUR ACCOUNT using this link: https://rda-login.wicketcloud.com/users/confirmation. Visitors may encounter functionality issues with group pages, navigation, missing content, broken links, etc. As you explore the new site, please provide your feedback using the UserSnap tool on the bottom right corner of each page. Thank you for your understanding and support as we work through all issues as quickly as possible. Stay updated about upcoming features and functionalities: https://www.rd-alliance.org/rda-web-platform-upcoming-features-and-functionalities/

#130588

Makx –
I agree these are excellent mechanisms – and we should preserve the discussions which – I believe – have been illuminating.
For me the problem persists: how to take abstract FAIR principles and turn them into concrete assertions to be challenged or questions which can be tested leading to metric values (binary or scalar)?
Your excellent landscape study indicates some approaches. The FAIRMetrics work (Go FAIR, FAIRSharing) seems very relevant.
I find the paper ‘FAIR Metrics Evaluation Results’ at ZIP at https://zenodo.org/record/1305060#.XMHGFehKhnI useful. However, many (most) of the answers are pointers to documents (and in some cases general documents not specific to the question or FAIR principle) and not a clear metric value. However the structure of the questions (and the sub-questions) is – I believe – relevant. Could we perhaps use their question structure as a basis and elaborate from there to specific assertions or questions to which the answers could be empirical metric values?
Best
Keith
——————————————————————————–
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
———————————————————————————————————————————-
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
———————————————————————————————————————————-
– Show quoted text -From: mail=***@***.***-groups.org On Behalf Of makxdekkers
Sent: 23 April 2019 12:59
To: ‘FAIR Data Maturity Model WG’
Subject: Re: [fair_maturity] Workshop #2 Report
Excellent point Barend.
I would like to suggest possible ways to handle these threads.
First, I am hoping that members are willing to contribute to the collaborative document at [1] by proposing specific indicators and maturity levels for the FAIR principles. Furthermore, on specific points, like what is ‘persistence’ and what is ‘rich metadata’, such indicators could include whether or not data is identified with DOIs or other commonly used identifier schemes, and whether metadata is provided conformant to DataCite kernel or some other standard set – it would be good to point to common or best practice in order to make sure that we’re not re-inventing any wheels.
Second, for any further discussion, issues could be raised on the mailing list. In that case, I would suggest that an e-mail (a) is about one issue and (b) has a sensible subject line, so that it is easier to follow the thread. Maybe people could also cut off some of the long tail of messages in the replies.
It is also possible to raise issues on GitHub at [2]. GitHub makes it easier to follow individual discussions and see how discussions lead to consensus, but if people are more comfortable with e-mail that is OK too. The editorial team will keep an eye on both e-mail and GitHub and will try to summarise every now and again how the discussions are progressing.
Many thanks, Makx.
[1] https://docs.google.com/spreadsheets/d/1gvMfbw46oV1idztsr586aG6-teSn2cPW
[2] https://github.com/RDA-FAIR/FAIR-data-maturity-model-WG/issues
From: barendmons=***@***.***-groups.org On Behalf Of Barend Mons
Sent: 23 April 2019 11:48
To: Keith Jeffery ; FAIR Data Maturity Model WG
Subject: Re: [fair_maturity] Workshop #2 Report
I think al lot of that we discuss here is ‘how’ rather than ‘what’
So maybe we should start a separate thread because the discussion as such is very valuable.
I also address the UPRI /Handle issue a bit in http://www.data-intelligence-journal.org/p/10/1/
I believe a prefix registry is scalable, and with automatically generated (hash for instance) suffixes, we should be fine
B
Makx –
I agree these are excellent mechanisms – and we should preserve the discussions which – I believe – have been illuminating.
For me the problem persists: how to take abstract FAIR principles and turn them into concrete assertions to be challenged or questions which can be tested leading to metric values (binary or scalar)?
Your excellent landscape study indicates some approaches. The FAIRMetrics work (Go FAIR, FAIRSharing) seems very relevant.
I find the paper ‘FAIR Metrics Evaluation Results’ at ZIP at https://zenodo.org/record/1305060#.XMHGFehKhnI useful. However, many (most) of the answers are pointers to documents (and in some cases general documents not specific to the question or FAIR principle) and not a clear metric value. However the structure of the questions (and the sub-questions) is – I believe – relevant. Could we perhaps use their question structure as a basis and elaborate from there to specific assertions or questions to which the answers could be empirical metric values?
Best
Keith
——————————————————————————–
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
———————————————————————————————————————————-
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
———————————————————————————————————————————-
From: mail=***@***.***-groups.org On Behalf Of makxdekkers
Sent: 23 April 2019 12:59
To: ‘FAIR Data Maturity Model WG’
Subject: Re: [fair_maturity] Workshop #2 Report
Excellent point Barend.
I would like to suggest possible ways to handle these threads.
First, I am hoping that members are willing to contribute to the collaborative document at [1] by proposing specific indicators and maturity levels for the FAIR principles. Furthermore, on specific points, like what is ‘persistence’ and what is ‘rich metadata’, such indicators could include whether or not data is identified with DOIs or other commonly used identifier schemes, and whether metadata is provided conformant to DataCite kernel or some other standard set – it would be good to point to common or best practice in order to make sure that we’re not re-inventing any wheels.
Second, for any further discussion, issues could be raised on the mailing list. In that case, I would suggest that an e-mail (a) is about one issue and (b) has a sensible subject line, so that it is easier to follow the thread. Maybe people could also cut off some of the long tail of messages in the replies.
It is also possible to raise issues on GitHub at [2]. GitHub makes it easier to follow individual discussions and see how discussions lead to consensus, but if people are more comfortable with e-mail that is OK too. The editorial team will keep an eye on both e-mail and GitHub and will try to summarise every now and again how the discussions are progressing.
Many thanks, Makx.
[1] https://docs.google.com/spreadsheets/d/1gvMfbw46oV1idztsr586aG6-teSn2cPW
[2] https://github.com/RDA-FAIR/FAIR-data-maturity-model-WG/issues
– Show quoted text -From: barendmons=***@***.***-groups.org On Behalf Of Barend Mons
Sent: 23 April 2019 11:48
To: Keith Jeffery ; FAIR Data Maturity Model WG
Subject: Re: [fair_maturity] Workshop #2 Report
I think al lot of that we discuss here is ‘how’ rather than ‘what’
So maybe we should start a separate thread because the discussion as such is very valuable.
I also address the UPRI /Handle issue a bit in http://www.data-intelligence-journal.org/p/10/1/
I believe a prefix registry is scalable, and with automatically generated (hash for instance) suffixes, we should be fine
B