search

OBOFoundry / OBOFoundry.github.io

Metadata and website for the Open Bio Ontologies Foundry Ontology Registry
http://obofoundry.org
Other
166 stars 204 forks source link

Principle #1 open - automated validation #1019

Closed beckyjackson closed 2 years ago

beckyjackson commented 5 years ago

FP 1 - Open

Automated checks:

  1. The ontology must have a license
  2. The license must be open

Mechanisms:

We already check for a license in the metadata validation. If there is a missing license, that check fails. We also issue a warning if the license is not a valid open license (CC0 or CC-BY).

This check would slightly change from the metadata validation in that it is required that the license is open. So if the ontology has a license other than one of those, this check will fail.

beckyjackson commented 5 years ago

The ontology file should also have a license in the file. This license should match the license in the registry file. The ontology should use the property http://purl.org/dc/terms/license.

If the license is not CC0/CC-BY, it receives a registry warning in the registry metadata validation. This check should be the same (WARN on non CC0/CC-BY).

balhoff commented 5 years ago

A lot of the ontologies with red Xs in the dashboard ("missing ontology license") do have a license. But they are using the http://purl.org/dc/elements/1.1/rights property. Could you check for this one and issue a warning on the property instead of a missing license error?

jamesaoverton commented 5 years ago

@balhoff I believe that using the wrong predicate is just a WARN, which seems right to me: https://github.com/OBOFoundry/OBOFoundry.github.io/blob/master/util/principles/fp_001.py#L25

balhoff commented 5 years ago

I think the issue is that dc:rights is not looked for as a "bad" property here: https://github.com/OBOFoundry/OBOFoundry.github.io/blob/47822c41a8ea7fda406063b291f21c4b9d09250c/util/principles/fp_001.py#L369-L372

jamesaoverton commented 5 years ago

Ok, thanks. I think we should add dc:rights as a predicate to check and WARN on. Would you mind making a PR?

matentzn commented 5 years ago

@beckyjackson if you could check this (docs with examples on how to format the licenses correctly):

https://github.com/INCATools/ontology-development-kit/blob/master/docs/License.md

I think its correct; I am using it for updating all the ontology I work with. If this is useful, we can move it here or to your own documentation; I dont mind where it lives!

allysonlister commented 4 years ago

In a slight variation on this ticket, SWO fails because I have my license in a sentence, e.g. "swo is provided under a creative commons attribution 4.0 international (cc by 4.0) license (https://creativecommons.org/licenses/by/4.0/)." Are you saying OBO is requesting that we just have the URL to the license? Or would such a sentence still be acceptable? Thanks!

jamesaoverton commented 4 years ago

@allysonlister In the current version of the Open principle we're recommending both: the dcterms:license is a URL, followed by an rdfs:comment with human-readable terms of reuse. Would that work for SWO?

allysonlister commented 4 years ago

This should work great - I'll add a ticket to SWO to remind me to update things at my end. Thanks!

jonquet commented 4 years ago

I do not suggest to use rdfs:comment to describe term of use. It not well qualified for this.

CC vocavualry provides the property you need: cc:useGuidelines A related resource which defines non-binding use guidelines for the work.

https://creativecommons.org/ns# See also : See: https://link.springer.com/article/10.1007/s13740-018-0091-5#Fn2

cmungall commented 4 years ago

Good recommendation thanks

On Wed, Feb 26, 2020, 02:08 Clement Jonquet notifications@github.com wrote:

I do not suggest to use rdfs:comment to describe term of use. It not well qualified for this.

CC vocavualry provides the property you need:

cc:useGuidelines A related resource which defines non-binding use guidelines for the work.

https://creativecommons.org/ns# See also : See: https://link.springer.com/article/10.1007/s13740-018-0091-5#Fn2

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1019?email_source=notifications&email_token=AAAMMONKPVLA3OTE4ZTSNS3REY5SJA5CNFSM4IKVMYWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM7TM5I#issuecomment-591345269, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOPWSP4KJ2NQWPM2JUTREY5SJANCNFSM4IKVMYWA .

ramonawalls commented 4 years ago

Really useful. I don't have comments beyond what has already been stated, but I will plus one some of those.

mcourtot commented 4 years ago

Why do we have both? I'm wondering whether we should only have the URL to the license OR the text description if there is no standard URL. What happens if the URL and the text contradict each other? For practicality the text will always be shorter than the full text of the licence, so will not cover all cases anyway.

matentzn commented 4 years ago

I think we should at least make clear that the http://purl.org/dc/terms/license annotation is prefered. This is what makes the whole thing computationally accessible! In the SWO case described by @allysonlister, this would make the rdfs:comment redundant in any case (we simply would not care whether there is another human-readable version of the license, in whatever shape or form - if there is a http://purl.org/dc/terms/license annotation; we neither forbid it nor encourage it). Is there really any case in which there is no URL that can be used to a license description?

jonquet commented 4 years ago

Why do we have both? Yes indeed. An ontology should/could have both. A property for describing the license itself (with possibly a URI proposed by the CC vocabulary as value) and a property to describe how to use the resource (with some text as value).

In our work on MOD/AgroPortal we have chosen : http://purl.org/dc/terms/license as "default" property to express the License but also found :

Because it's hard to enforce the use of a specific property, when an ontology is uploaded to AgroPortal, any of these properties will be used to populate the common "license" property in our model (which is itself expressed by dct:license).

To refine the license we have also included in our model :

nlharris commented 2 years ago

Are there still action items here?

matentzn commented 2 years ago

No, this was a fruitful discussion but for now, we will stick with our current principle of requiring an open license with dcterms:license. @balhoff I don't want to close this issue here without your consent, but I feel like allowing dct:rights as an alternative to license will just lead to less clarity in our communications. I think an explicit license must be provided no matter what. Anything else is optional!

If you agree @balhoff this issue can be closed.

balhoff commented 2 years ago

@matentzn my request wasn't about allowing dct:rights as an alternative to license. It was just to make the message more informative. Instead of saying that their license is missing, it was to say that they have a license but used the wrong property. And we already addressed that in https://github.com/OBOFoundry/OBO-Dashboard/pull/8. I'm fine with closing this issue.

matentzn commented 2 years ago

I never realised this was happening.. Before my time! :) Thanks for the clarification!