Release ELK with support of OWL API 5

[matentzn]

I am not sure whether it is a bad on my end, but is there an integration of ELK with OWL API 5 yet? ELK 0.5 still seems to depend on an oldish version of OWLAPI 4 (the snapshot integrated via MAVEN).

[ykazakov]

Duplicate of #45

[ykazakov]

@matentzn can you give a bit more details about what is on your end? How do you use ELK from maven? What does not work?

ELK uses the OWL API 4 dependency (at the moment v. 4.2.7), that does not however mean it should not work with other versions of OWL API. In this regards, it is no different to any other kind of transitive maven dependencies.

[matentzn]

I tried using it with 5, but there are some missing methods in 5 your code is referencing. OWLAPI 4 and 5 are not fully downwards compatible.

In a fresh project importing ELK 0.5 snapshot and OWL API 5.1.4, instantiate ELK in this way:

OWLOntology o = OWLManager.createOWLOntologyManager().loadOntologyFromOntologyDocument(IRI.create("https://raw.githubusercontent.com/obophenotype/upheno/master/imports/hsapdv_import.owl")); OWLReasoner r = new ElkReasonerFactory().createReasoner(o); System.out.println(r.isConsistent());

The following exception will be thrown:
Exception in thread "main" java.lang.NoSuchMethodError: org.semanticweb.owlapi.model.OWLTransitiveObjectPropertyAxiom.getProperty()Lorg/semanticweb/owlapi/model/OWLPropertyExpression; at org.semanticweb.elk.owlapi.wrapper.ElkTransitiveObjectPropertyAxiomWrap.getProperty(ElkTransitiveObjectPropertyAxiomWrap.java:52) at org.semanticweb.elk.owlapi.wrapper.ElkTransitiveObjectPropertyAxiomWrap.getProperty(ElkTransitiveObjectPropertyAxiomWrap.java:41) at org.semanticweb.elk.reasoner.indexing.conversion.ElkAxiomConverterImpl.visit(ElkAxiomConverterImpl.java:358) at org.semanticweb.elk.reasoner.indexing.conversion.ElkAxiomConverterImpl.visit(ElkAxiomConverterImpl.java:90) at org.semanticweb.elk.reasoner.indexing.classes.DelegatingElkAxiomVisitor.visit(DelegatingElkAxiomVisitor.java:243) at org.semanticweb.elk.reasoner.indexing.classes.NonIncrementalElkAxiomVisitor.visit(NonIncrementalElkAxiomVisitor.java:78) at org.semanticweb.elk.reasoner.indexing.classes.NonIncrementalElkAxiomVisitor.visit(NonIncrementalElkAxiomVisitor.java:46) at org.semanticweb.elk.owlapi.wrapper.ElkTransitiveObjectPropertyAxiomWrap.accept(ElkTransitiveObjectPropertyAxiomWrap.java:67) at org.semanticweb.elk.owlapi.wrapper.ElkTransitiveObjectPropertyAxiomWrap.accept(ElkTransitiveObjectPropertyAxiomWrap.java:57) at org.semanticweb.elk.owlapi.wrapper.ElkObjectPropertyAxiomWrap.accept(ElkObjectPropertyAxiomWrap.java:48) at org.semanticweb.elk.reasoner.indexing.classes.ChangeIndexingProcessor.visit(ChangeIndexingProcessor.java:73) at org.semanticweb.elk.owlapi.OwlOntologyLoader.load(OwlOntologyLoader.java:136) at org.semanticweb.elk.reasoner.stages.InputLoadingStage.executeStage(InputLoadingStage.java:228) at org.semanticweb.elk.reasoner.stages.AbstractReasonerStage.execute(AbstractReasonerStage.java:148) at org.semanticweb.elk.reasoner.stages.InputLoadingStage.execute(InputLoadingStage.java:70) at org.semanticweb.elk.reasoner.stages.LoggingStageExecutor.execute(LoggingStageExecutor.java:52) at org.semanticweb.elk.reasoner.stages.AbstractStageExecutor.complete(AbstractStageExecutor.java:46) at org.semanticweb.elk.reasoner.stages.AbstractReasonerState.complete(AbstractReasonerState.java:225) at org.semanticweb.elk.reasoner.stages.AbstractReasonerState.ensureLoading(AbstractReasonerState.java:369) at org.semanticweb.elk.reasoner.stages.AbstractReasonerState.restoreSaturation(AbstractReasonerState.java:381) at org.semanticweb.elk.reasoner.stages.AbstractReasonerState.isInconsistent(AbstractReasonerState.java:468) at org.semanticweb.elk.owlapi.ElkReasoner.isConsistent(ElkReasoner.java:954) at RunELK.main(RunELK.java:14)

[matentzn]

For now I downgraded my codebase to OA4, because I really need ELK.. Would be cool if someone could take care of that one day, because I really like using the OA5 streams.

[ykazakov]

You code works fine for me with OWL API 5.1.4 and ELK 0.5.0-SNAPSHOT and returnstrue.
Here is my pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>org.liveontologies</groupId>
	<artifactId>elk-owlapi5-tryout</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<dependencies>
		<dependency>
			<groupId>org.semanticweb.elk</groupId>
			<artifactId>elk-owlapi</artifactId>
			<version>0.5.0-SNAPSHOT</version>
		</dependency>
		<dependency>
			<groupId>net.sourceforge.owlapi</groupId>
			<artifactId>owlapi-distribution</artifactId>
			<version>5.1.4</version>
		</dependency>
	</dependencies>

	<repositories>
		<repository>
			<!-- the repository for snapshot dependencies -->
			<id>ossrh</id>
			<url>https://oss.sonatype.org/content/repositories/snapshots</url>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
			<releases>
				<enabled>false</enabled>
			</releases>
		</repository>
	</repositories>

</project>

Also, OWL API 5.1.4 has the method org.semanticweb.owlapi.model.OWLTransitiveObjectPropertyAxiom.getProperty()Lorg/semanticweb/owlapi/model/OWLPropertyExpression, which can be tested using this code:

OWLDataFactory f = OWLManager.getOWLDataFactory();
		OWLObjectProperty t = f
				.getOWLObjectProperty(IRI.create("http://test.org/t"));
		OWLTransitiveObjectPropertyAxiom ax = f
				.getOWLTransitiveObjectPropertyAxiom(t);
		System.out.println(ax.getProperty());

[matentzn]

Hmm. I must be missing something crucial. I looked at the specs and you are right, getProperty() can be found in a super interface of the one in question. But the exception is still thrown. Can you try to explicitly exclude OA4?

`<project ...>
4.0.0

<groupId>nico</groupId>
<artifactId>tets</artifactId>
<version>1.0-SNAPSHOT</version>


<properties>
    <java.version>1.8</java.version>
</properties>

<dependencies>
    <!-- https://mvnrepository.com/artifact/net.sourceforge.owlapi/owlapi-distribution -->
    <dependency>
        <groupId>org.semanticweb.elk</groupId>
        <artifactId>elk-owlapi</artifactId>
        <version>0.5.0-SNAPSHOT</version>
        <exclusions>
            <exclusion>
                <groupId>net.sourceforge.owlapi</groupId>
                <artifactId>owlapi-api</artifactId>
            </exclusion>
            <exclusion>
                <groupId>net.sourceforge.owlapi</groupId>
                <artifactId>owlapi-impl</artifactId>
            </exclusion>
            <exclusion>
                <groupId>net.sourceforge.owlapi</groupId>
                <artifactId>owlapi-apibinding</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
   <dependency>
        <groupId>net.sourceforge.owlapi</groupId>
        <artifactId>owlapi-distribution</artifactId>
        <version>5.1.4</version>
    </dependency>


</dependencies>
<repositories>
    <repository>
        <id>sonatype-nexus-snapshots</id>
        <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
        <releases>
            <enabled>false</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>
<build><plugins>
    <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
        </configuration>
    </plugin>
</plugins></build>

`

[ykazakov]

You are right. It does not work this way. Something is messed up with the class loader. I'll investigate.

As a workaround, you can compile a version of ELK with OWL API 5 by activating the owlapi5 profile.

mvn clean install -Powlapi5

Then remove the sonatype repository from pom to prevent the current snapshot version being pulled (or rename the ELK version to something else).

[matentzn]

Ok, cool. That works for now! Thanks. I would like to keep this issue open though until we have a owlapi 5 compatible release on Maven central.. If you dont mind!

[ykazakov]

Interestingly, if I compile ELK with owapi5 but then use with your code in OWL API 4, then it works fine. Perhaps we can then switch to the OWL API 5 dependency by default, but then one needs to actually test that the produce jar works with v. 4 and there are no class loader problems like this.

[matentzn]

I would not recommend that. The majority of projects I think still work on 4, and they should get that major release as well. I think you should consider that 4 and 5 are really not compatible. My humble view is that the community is served best with separate releases for OA4 and OA5, under different version numbers (perhaps 0.4.4 vs 0.5). It would also help with project setup not being messed up too much by wrong OA versions being imported and making it onto the classpath.. :) What do you think?

[ykazakov]

What makes sure that a jar compiled with OA 5.1.x is compatible with OA 5.2.y and a jar for OA 4.5.x is compatible with OA 4.3.x? We cannot release a separate version of ELK for every possible (major or minor) version of OWL API. Otherwise, you will have to deal with the dependency mess anyway (e.g., exclude 4.5.1 dependency and include 4.5.4 when you use OA 4.5.4).

My idea was to avoid using APIs that have changed between the version, so that one jar works with all of them. But for some reason it doesn't.

[matentzn]

As far as I understand, the current OA 4 and 5 releases are stable in terms of API.

@ignazio1977 Do you have any advice for this issue?

My feeling is that ELK is already, and will be, the one most important tool our domain uses for reasoning for years to come. A proper solution would be really desirable. (I am working for EBI now and they use ELK everywhere).

[ykazakov]

Regarding stability of OWL API API, there is an interesting ticket: owlcs/owlapi#624

In general, the problem is not new or unique to ELK (there are tons of software that use different versions of common libraries, like guava, slf4j, apache-commons, and everything somehow works).
I think the solution in our case will be as before: we will gradually migrate to a new version of OWL API (like we already did already with 3 => 4), and those who stuck with an old version of OA should just use the older version of ELK.
At the moment the only issue stopping us from migrating to OA 5 is Protege. I did a quick test, and it seems though that ELK compiled with OA 5 works fine with P4. If it is really the case, then there is no brainer to switch to OA 5. Just need to find a way how to reliably test that the OA5-comiped jar works with OA 4.

[ignazio1977]

Regarding stability of OWL API API, there is an interesting ticket: owlcs/owlapi#624

Interesting indeed. The semantics of adding new methods to public classes (not interfaces) in terms of OSGi numbering are fascinating. Or maddening, depending. However, it is true that there will be no major changes to OWLAPI 5, as far as I can tell.

Re Protege, by the same coin ELK should be able to use OWLAPI 5 - if it starts properly, that means the OWLOntology and the OWLReasoner interfaces work well between Protege and ELK. I thought that's where things would fail, actually, as that's where the host app and the bundles interact. It's also the main obstacle in Protege development, I'm told - it's hard to sort all plugins to work on a new OWLAPI version.