Updating ELK 0.43 to 0.5

[matentzn]

Resolves #380 #660

• docs/ have been added/updated (NOT NECESSARY)
• tests have been added/updated
• mvn verify says all tests pass
• mvn site says all JavaDocs correct
• CHANGELOG.md has been updated

This pull request migrates ELK to the 0.5 version. I have tested it in various ODK pipelines, and bundled it with the latest ODK:dev image.

[matentzn]

@jamesaoverton and I discussed this and we will move this to a future version of ROBOT, maybe ROBOT 2.0 :P

[balhoff]

@matentzn @jamesaoverton I think it's a high priority for us to get ELK 0.5 into ROBOT. I started to look at publishing a version in one of our own orgs, so we wouldn't need to use the snapshot repo (which I think would prevent ROBOT from being published to Maven central). But I found this one already on Maven central: https://search.maven.org/artifact/au.csiro/elk-owlapi4/0.5.0/jar

Can we just use that for the time being?

[matentzn]

I would suggest we do this asap:

1. Start version Dev ODK
2. Create an experimental ROBOT Elk 0.5 version of ROBOT and load it into ODK-dev
3. We migrate all our universe to that ELK (esp. Github actions)
4. Maybe even make a proper parallel robot release for people to test
5. Use this for a while. Once all issues in the main OBO ontologies are identified and ironed out, we can schedule a proper ROBOT release.

Unless someone figures out how to have elk 0.4 and 0.5 co-exist, I am a bit worried who will deal with the 1 billion support issues coming from unsats revealed by 0.5.

[jamesaoverton]

I never tried to use two versions of the same dependency in a Java project before. Some quick research makes it look like black magic to me, but if someone else has experience then let us know.

I'm OK with creating a ROBOT branch and beta release robot-1.9.1-elk-0.5.0.jar (or something) using ELK 0.5. (Most of my projects use HermiT, so I haven't personally seen the problems with this ELK update.)

[matentzn]

Maybe I am overthinking this. @jamesaoverton and I have decided to make a quick experiment with OBO Dashboard and see what will happen if we simply swap in ELK 0.5. Basically, we will compare unsats with ELK 0.4.3 and make a decision based on that.

[matentzn]

Sorry I forgot it again @jamesaoverton. Was it somehow possible to run an action and obtain a ROBOT jar from a branch using a URL (this makes it easy to inject a DEV version of ROBOT into ODK)?

[matentzn]

Ok, assigned this to @anitacaron, but it will have to wait until mid February until after the OntoSummit Dashboard session is finished: OBOFoundry/OBO-Dashboard#82

[jamesaoverton]

Was it somehow possible to run an action and obtain a ROBOT jar from a branch using a URL (this makes it easy to inject a DEV version of ROBOT into ODK)?

Kinda. Our GitHub Actions do create a JAR file that you can download with a browser, BUT the link uses some JavaScript so you don't get a URL that you can just curl, and they expire after 90 days (or something). So this GitHub Actions logs and artifacts for this PR have expired.

I'll try to make a pre-release here in the repo.

[jamesaoverton]

Here is a pre-release with an attached JAR: https://github.com/ontodev/robot/releases/tag/v1.9.1-elk-0.5.0

I didn't know how to test that it actually includes ELK 0.5.0, so please confirm that before running hours of tests.

[ghost]

@jamesaoverton, checking in on this PR. Editors are switching over to Protégé 5.6.1 which has ELK 0.5.0. Based on the thread above, it is not clear what the next step is to update ROBOT to 0.5.0 and who needs to do it. Is there something specific someone needs to do to move this forward so Protégé and ROBOT can be aligned? Thanks for your attention.

[matentzn]

@bvarner-ebi thanks for pushing, this is on me. I will soon create a ODK dev release with ELK 0.5 for testing

[matentzn]

ELK 0.5 did not recognise this ontology (in a test) as incoherent, because it reverted to a wrong branch in the unsatisfiability testing framework in ROBOT due to an incomplete implementation (liveontologies/elk-reasoner#66).

Prefix: : <http://x.org/>

Ontology: <http://purl.obolibrary.org/obo/test>

Class: C
Class: O
   DisjointWith: C

ObjectProperty: P
  Domain: C
ObjectProperty: Q
  Domain: O
    SubPropertyOf: P

Seems that ELK 0.43 was able to for some reason. Replicated this in Protege as well.

EDIT: this is now dealt with: liveontologies/elk-reasoner#66

[matentzn]

This is necessary because of liveontologies/elk-reasoner#66 (comment)

Basically, ELK 0.5 (as opposed to 0.43) claims to implement OBJECT_PROPERTY_HIERARCHY, but it does not recognise unsatisfiable object properties (or at least, not the one we are looking for in the test for incoherentRBox).

[jclerman]

Thanks @matentzn for tracking down the cause and for this solution! I'm glad that it didn't require reverting the faster inference when using Hermit - that's been a huge boon in my workflow.

[matentzn]

Given my new awesome diff system, I determined these cases with difference in unsats:

Differences in the number of unsatisfiable classes comparing Elk 0.4.3 and Elk 0.5

ontology	0.4.3	0.5
ontoneo	21	23
aism	0	1238
upheno	60521	83201
psdo	21	46
rbo	0	1
nomen	0	1
kisao	21	28
ecocore	0	9

cc @FernandaFarinelli @JCGiron @zachll @DanBerrios @mjy @jonrkarr @pbuttigieg

I hereby officially make my recommendation that this should be merged - its thoroughly tested, and ready for action. The differences in unsats are only revealing problems that are already there.

[jamesaoverton]

I don't have a good way to test this, so I'm taking @matentzn at his word.