Ontology: The OEO license is not reconized by the databus

[Ludee]

Description of the issue

There is an automated check of the ontology on the databus.
Some test fail, I'm not sure which and how to fix them.

https://databus.dbpedia.org/ontologies/openenergy-platform.org/ontology--oeo

Ideas of solution

• [x] Identify check and missing score
• [x] Fix it

[Ludee]

Archivo needs an license IRI: http://archivo.dbpedia.org/info?o=http://openenergy-platform.org/ontology/oeo/

The OEO states:
dct:license "http://creativecommons.org/publicdomain/zero/1.0/"
https://github.com/OpenEnergyPlatform/ontology/blob/master/src/ontology/oeo.omn#L47

It also seems to not follow the LODE service:
https://essepuntato.it/lode/

[Ludee]

The license URL was written as _Literal_ (text). I used the tab _IRI Editor_ to make it a proper IRI:

dct:license <http://creativecommons.org/publicdomain/zero/1.0/>,

This should fix the issue.

I will open new issues for other constraints failing, e.g. _Semantic Version_

[l-emele]

@Ludee: In which PR did you change this? In the current dev branch it is still dct:license "http://creativecommons.org/publicdomain/zero/1.0/"

[sfluegel05]

There didn't seem to be a PR yet so I opened one.

[JJ-Author]

@Ludee the fix for the license is good. w.r.t to semantic version no actions is needed on your side. that is a problem of OWL API we use which has some problems with several ontologies although they seem formally correct.

[sfluegel05]

After release 1.5 Archivo doesn't recognize our license anymore: https://archivo.dbpedia.org/info?o=http://openenergy-platform.org/ontology/oeo/
I don't know why this happened, the license statement has not been changed since the last release.

[JJ-Author]

Hey @sfluegel05 it should be
dct:license <http://creativecommons.org/publicdomain/zero/1.0/>

then it is correct again. See https://archivo.dbpedia.org/download?o=http%3A//openenergy-platform.org/ontology/oeo/&f=nt&v=2021.03.02-180405
So somebody touched it ;-).

@yum-yab https://github.com/yum-yab is happy to get your feedback, what is confusing to you. Because he put a lot of effort to make the report and star rating transparent https://github.com/dbpedia/archivo

[sfluegel05]

After taking a closer look at it, the problem seems to be that the release version is missing some axioms. The oeo-full version available at archivo or on https://openenergy-platform.org/ontology/oeo uses description, title and licence from oeo-social.omn instead of oeo.omn. The licence in oeo-social.omn was indeed the wrong one and this has been fixed in #747 (after the release), so the star rating is working fine.

There seems to be something wrong with the released oeo-full version however. According to the Protege metrics it has 8563 axioms, while the dev/oeo.omn-version at that time had 8889 axioms. For example, the dc:contributor-axioms are missing. Maybe @MGlauer knows more about why this happened or how to fix it.

[MGlauer]

We are using robot merge to create the oeo-full.omn-files and robot convert to translate the .owl-files into .omn-files. I have a hunch, why the oeo-social is taking preference, but I guess the missing axioms are just dropped by robot!?

[l-emele]

How important is this problem? Does it justify a hotfix release after solving the problem?

[MGlauer]

IIRC this has been fixed by @sfluegel05, but the issue has not been closed

[sfluegel05]

I didn't fix this and I am also not sure what to do exactly.

[jannahastings]

@MGlauer we need to look at the build process step where the relevant annotation is getting dropped, it may be possible to address the problem by changing the order of files passed to robot or by adding some parameters to robot?

[MGlauer]

The licence issue originated from the inconsistency in the licence attribute used amongst different files and should have been fixed with #747. The next release should use the proper license attribute.
@jannahastings: Agreed. I do not recall any changes that might have led to this behaviour. We should look into the exact behavior of robots merge method.

[sfluegel05]

After the latest release (v1.6.1) everything seems to be fine, so I will close this issue for now.