Principle #1 open - automated validation

[beckyjackson]

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]

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]

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]

@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]

I think the issue is that dc:rights is not looked for as a "bad" property here:

OBOFoundry.github.io/util/principles/fp_001.py

Lines 369 to 372 in 47822c4

	# correct dc license property namespace
	license_prop = 'http://purl.org/dc/terms/license'
	# incorrect dc license property namespace
	bad_license_prop = 'http://purl.org/dc/elements/1.1/license'

[jamesaoverton]

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

[matentzn]

@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]

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]

@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]

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

[jonquet]

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]

Good recommendation thanks

…

On Wed, Feb 26, 2020, 02:08 Clement Jonquet ***@***.***> 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 <#1019?email_source=notifications&email_token=AAAMMONKPVLA3OTE4ZTSNS3REY5SJA5CNFSM4IKVMYWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM7TM5I#issuecomment-591345269>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOPWSP4KJ2NQWPM2JUTREY5SJANCNFSM4IKVMYWA> .

[ramonawalls]

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

[mcourtot]

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]

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]

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 :

• http://creativecommons.org/ns#license
• http://omv.ontoware.org/2005/05/ontology#hasLicense
• http://purl.org/dc/elements/1.1/rights
• http://purl.org/dc/terms/license
• http://purl.org/dc/terms/rights
• http://schema.org/license

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 :

• dct:publisher (with mappings to dc:publisher, schema:publisher) : "An entity responsible for making the ontology available"
• cc:morePermissions (with no mappings): "A related resource which describes additional permissions or alternative licenses"
• schema:copyrightHolder (with no mappings): "The party holding the legal copyright to the CreativeWork."

[nlharris]

Are there still action items here?

[matentzn]

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]

@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 OBOFoundry/OBO-Dashboard#8. I'm fine with closing this issue.

[matentzn]

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