-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indicators for R1.1: (meta)data are released with a clear and accessible data usage licence #27
Comments
Points raised in online meeting 3 on 18 June 2019
|
I suggest this is insufficient. A licence is most likely human readable and not machine understandable. For autonomic interoprability it is necessary to extract from the licence assertions or rules in logic that can be used to determine whether at this time from this place this software acting on behalf of this user from this organisation in this role can access (and conditionally perform other operations on) the asset and if so what is recorded about the access (e.g. citation, accreditation, audit logging, provenance, curation). |
@keithjeffery These are indeed important aspects of a licence. However, I think we also need to be realistic. I would say that possibly very few existing licences in use for research data provide this level of detail. There is some of this in ccRel and in ODRL but I don't know how widespread these are. Are there detailed descriptions of permissions and obligations for commonly used licences (e.g. CC-BY) publicly available? Would including these very detailed requirements in an indicator not make it too difficult for any data to be considered FAIR? I guess we don't want to end up in a situation that someone says "my data is CC-BY" and the evaluation concludes that the data, because of that, is not FAIR. It would make FAIRness hard to achieve. Could we enumerate a smaller set of crucial licence information, plus useful, but not mandatory extensions? |
Makx –
You suggest
Could we enumerate a smaller set of crucial licence information, plus useful, but not mandatory extensions?
I think this is the optimal approach
Best
Keith
…--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: [email protected]<mailto:[email protected]>
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: makxdekkers <[email protected]>
Sent: 01 July 2019 17:01
To: RDA-FAIR/FAIR-data-maturity-model-WG <[email protected]>
Cc: Keith Jeffery <[email protected]>; Mention <[email protected]>
Subject: Re: [RDA-FAIR/FAIR-data-maturity-model-WG] Indicators for R1.1: (meta)data are released with a clear and accessible data usage licence (#27)
@keithjeffery<https://github.com/keithjeffery> These are indeed important aspects of a licence. However, I think we also need to be realistic. I would say that possibly very few existing licences in use for research data provide this level of detail. There is some of this in ccRel and in ODRL but I don't know how widespread these are. Are there detailed descriptions of permissions and obligations for commonly used licences (e.g. CC-BY) publicly available?
Would including these very detailed requirements in an indicator not make it too difficult for any data to be considered FAIR? I guess we don't want to end up in a situation that someone says "my data is CC-BY" and the evaluation concludes that the data, because of that, is not FAIR. It would make FAIRness hard to achieve.
Could we enumerate a smaller set of crucial licence information, plus useful, but not mandatory extensions?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#27>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADALU56ISTZO2PIAMJUP5KLP5IS4JANCNFSM4H25663A>.
|
@keithjeffery OK, let's then try to get some more opinions and suggestions from others in the WG. |
you might be interested in the indicators outlined here: http://reusabledata.org/ |
as a general comment, we expect that maximum FAIRness is achieved when machines can interpret the terms and conditions in a license (see also smart contract) |
@micheldumontier Do you think it is possible to require existing licences (e.g. CC-BY) to be fully machine-understandable, e.g. with explicit permissions, prohibitions, obligations etc., the way ODRL does? If so, could the third indicator above be reformulated as: Machine-understandable licence
|
@makxdekkers I think that this is highly desirable, yes. |
I would make this a tiered-metric (as we have done for several of the Maturity Indicators in our project). The idea of having a "license - weak compliance" metric, that says "can a machine FIND the license, regardless of what it's value is"; and then a second metric "license - strong compliance", that says "can a machine process the license that it finds". At least for the moment, being able to FIND the license in most metadata records is already a struggle, because existing standards are not well-harmonized around this property. Looking at the LOV registry, I see ~13 distinct predicates that could be interpreted as pointing at some kind of license. It would be nice if that could be pruned down to a small handful. Then, to look at machine-readability of the value of those predicates (where even "readability" is tricky - a lot of the CC licenses have an RDF presentation, that reflects the common structural components of a license, but the content is not processable by machines...) |
@markwilkinson The indicators in the first comment in this issue already have the presence of a licence as an indicator. The additional one that I proposed after @micheldumontier' comment is about the machine-understandability of the licence in terms of permissions, obligations etc. |
Yes, I want a specific metadata element. Without that, I can't find the "thing" that is supposed to represent the license. (unless we go full-on OWL, and then I can check the rdf:type of every value of every metadata element to figure out which one is of type "License" ;-) ) |
@markwilkinson But how can a specific metadata element be mandated? Where licence information is provided depends on the community standard, doesn't it? Community standards usually have a clear place to provide a link to a licence (DC/DCAT has |
Oh! No, I meant exactly that - that there should BE such an element, formally designated as such by that community, rather than just a randomly coined predicate. |
@markwilkinson That's a relief! R1.1-05 Provision of licence information in the appropriate element in the metadata standard used
On the other hand, isn't that a quality issue? In a way, if metadata does not use the appropriate metadata element, it would also fail on R1.3 as it would not (correctly) follow the relevant community standard. |
@makx - |
@keithjeffery Are you proposing an additional indicator? E.g.: R1.1-06 Provision of machine-understandable licence information
|
Makx_
Exactly – you caught my intention
Best
Keith
…--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: [email protected]<mailto:[email protected]>
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: makxdekkers <[email protected]>
Sent: 11 July 2019 10:37
To: RDA-FAIR/FAIR-data-maturity-model-WG <[email protected]>
Cc: Keith Jeffery <[email protected]>; Mention <[email protected]>
Subject: Re: [RDA-FAIR/FAIR-data-maturity-model-WG] Indicators for R1.1: (meta)data are released with a clear and accessible data usage licence (#27)
@keithjeffery<https://github.com/keithjeffery> Are you proposing an additional indicator? E.g.:
R1.1-06 Provision of machine-understandable licence information
* NO machine-understandable licence information (e.g. the human-readable title of a licence)
* Machine-understandabñle licence information (e.g. as provided by Creative Commons at https://creativecommons.org/licenses/by/3.0/rdf)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#27>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADALU52MFV4S3RTPTQCWTILP635KDANCNFSM4H25663A>.
|
Please find the current version of the indicator(s) and their respective maturity levels for this FAIR principle. Indicators and maturity levels will be presented, as they stand, to the next working group meeting for approval. In the meantime, any comments are still welcomed. The editorial team will now concentrate on weighing and prioritizing these indicators. More information soon. |
Dear contributors, Below you can find the indicators and their maturity levels in their current state as a result of the above discussions and workshops. Please note that this thread is going to be closed, within a short period of time. The current state of the indicators, as of early October 2019, is now frozen, with the exception of the indicators for the principles that are concerned with ‘richness’ of metadata (F2 and R1). The current indicators will be used for the further steps of this WG, which are prioritisation and scoring. Later on, they will be used in a testing phase where owners of evaluation approaches are going to be invited to compare their approaches (questionnaires, tools) against the indicators. The editorial team, in consultation with the Working Group, will define the best approach to test the indicators and evaluate their soundness. As such, the current set of indicators can be seen as an ‘alpha version’. In the first half of 2020, the indicators may be revised and improved, based on the results of the testing. If you have any further comments, suggestions regarding that specific discussion, please share them with us. Besides, we invite you to have a look at the following two sets of issues. Prioritisation • Indicators prioritisation for Findability Scoring • Indicators for FAIRness | Scoring |
The text was updated successfully, but these errors were encountered: