-
Notifications
You must be signed in to change notification settings - Fork 41
Display of ontology license information on OLS web inconsistent? #474
Comments
Example [2] is wrong, because the range of All of the other examples should work. I will look into this. |
We have looked into this issue briefly. It seems the problem stems from the fact that OLS does not deal explicitly will license related annotations (as it deals with for example version- or creator annotations), but rather detects it accidentally as part of the arbitrary ontology annotations. Given our current roadmap we will only be able to get to this issue by the end of June. If you need this rather urgently you welcome to implement a fix (similar to how we deal with the creator annotation) for this and to submit a pull request when ready. |
…and added links for URL type rights and license annotations for EBISPOT#474
|
At TIB we are working towards having several OLS instances running to provide a look up service to the many ontologies used throughout its labs and projects.
We recently encountered an inconsistency on how the license information from ontologies indexed by OLS frontend (ols-web) gets rendered (or not).
We understood that an ontology's displayed license is fetched from the ontology owl/ttl Dublin Core
dct:license
ordct:rights
property. However we are seeing inconsistencies, resulting in the license being displayed or not [3], or if the full license URL is shown or only the version [4].What causes this and how can it be fixed?
Another related question, is whether the license information is needed in the ontologies configuration file
obo-config.yaml
, if this information is gathered from the ontology owl?Compare the following examples:
<terms:license rdf:resource="https://creativecommons.org/licenses/by/3.0/"/>
<terms:license>http://creativecommons.org/licenses/by/4.0/</terms:license>
<terms:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/"/>
<dcterms:license rdf:resource="https://www.apache.org/licenses/LICENSE-2.0"/>
[1]
[2]
[3]
[4]
[5]
We would appreciate if someone could offer some clarification on this issue.
Thank you
The text was updated successfully, but these errors were encountered: