Generate reasoned version of PaNET

[paulmillar]

Motivation:

From issue #120:

[Support] users that want to exploit it using SPARQL queries, or simple python scripts. In the case of a clean Tbox the user looses all the inferred axioms and possibly some valuable results.

Modification:

Update build script to v0.5. This includes support for building an additional "reasoned" version of the ontology as source/PaNET_reasoned.owl.

Update the workflow to capture this additional artefact when uploading to GitHub.

Result:

We now build (and make available) both an unreasoned and a reasoned version of the ontology.

Closes: #120

[paulmillar]

The CI/CD pipeline is blocked until the pull request is reviewed; however, the reviewer may wish to see the generated artefacts when reviewing the pull request.

To get around this Catch-22 situation, the generated artefacts are already available from the origin branch (on my fork of PaNET).

In particular, both versions are available from the "PaNET" artifact from this run.

[gkoum]

From a quick check reasoning seems to work as in protege DL query tab and can successfully answer SPARQL queries.

[paulmillar]

Do we have a way for someone to easily get the script that builds PaNET should he needs to?

The script is available from the PaNET build repo, as the file build-panet.

The repo's README describes how to use it, but the container is perhaps the easiest way to build PaNET, as that also brings all the dependencies (widoco+java and obo-robot), so it should "just work".

Maybe even keep it in the PaNET repository...

Personally, I like to separate the build machinery (such as the script) from the thing being built, as it allows each to be maintained independently of the other.

So I'd be (mildly) in favour of keeping the build script (and Docker file) separate from PaNET itself.

I could move the repo's contents into GitHub (rather than DESY's gitlab), but then I think it should be a new repo, separate from PaNET.

[gkoum]

Yes it is clearer if it is separate but then it should be easy to get to the build script. Maybe we just need to add the path to the script in the Readme of the project if it is not already there and I missed it.

And a silly question from a github newbie: in the documentation we mention that there are folders like:

the releases folder contains the different releases of the PaNET ontology,

the gh-pages branch contains the ontology documentation (produced automatically by a GitHub action). 

but I cannot locate them.

[paulmillar]

Yes it is clearer if it is separate but then it should be easy to get to the build script. Maybe we just need to add the path to the script in the Readme of the project if it is not already there and I missed it.

I've created #138 so we remember to fix this.

And a silly question from a github newbie: in the documentation we mention that there are folders like [...]

This is out-of-date information.

Releases are no longer stored in git (that was a bad idea). Instead, they are stored as GitHub releases.

The docu is still generated automatically (by the build script). The CI/CD deploys this on the web pages if the build was triggered by tagging the repo with a tag that "looks like" a release.

I've created #139 so we can remember to fix this, too.