Release ELK with support of OWL API 5 #48
Comments
|
Duplicate of #45 |
|
@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. |
|
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:
The following exception will be thrown: |
|
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. |
|
You code works fine for me with OWL API 5.1.4 and ELK 0.5.0-SNAPSHOT and returns Also, OWL API 5.1.4 has the method |
|
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 ...> ` |
|
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. Then remove the sonatype repository from pom to prevent the current snapshot version being pulled (or rename the ELK version to something else). |
|
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! |
|
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. |
|
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? |
|
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. |
|
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). |
|
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). |
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. |
|
Regarding ELK and its importance in the community, definitely true - speaking of which, if there's any need for help in upgrading, please let me know. |
|
I think I have some explanation regarding the thrown For OWL API 4.5.1 this gives me: For OWL API 5.1.4 I obtain: Notice the different return types: OWLObject instead of OWLPropertyExpression. Why? Because in OWL API 4 Now it is also clear why the jar compiled with OWL API 5 works for OWL API 4, at least in this case: because the output type So to sum up: binary compatibility is a very tricky issue. |
|
Indeed, binary compatibility is hard. In order to properly get this to work (any version of a reasoner to work with any version of OWLAPI) I think the only possibility would be a separate API definition, e.g., the api module released as 1.0.0 and never changed afterwards. However that has its own drawbacks, obviously - we'd need to get it perfect the first time, or forever live with the mistakes. The alternative is incompatible changes between major versions, like in this case. Some are obvious (method name changes, new methods, old classes disappearing) other are subtle, like the one you spotted here, or like the incompatibility between an old version of Pellet and Java 7 (something to do with a new method with generic arguments in Map, if I remember correctly?)
5.2 is meant to be backwards compatible with 5.1, unless changes were required to fix bugs (same in general for all minor versions). I can't give a 100% guarantee, but that's the intent. The second case is harder - a newer version might have acquired a new functionality that the client code uses, and the older version might not have it, and sometimes a bug fix might cause the same sort of problems. |
Make some fixes to ensure that ELK jar compiled with OWL API 4.x works with OWL API 5.x
Address issue #48 new modules: - elk-owlapi-parent now contains the ELK OWL API modules for both OWL API version 4 and 5: elk-owlapi4, elk-owlapi5 - elk-distribution-parent now contains separate module for every distribution type: elk-distribution-cli, elk-distribution-owlapi4, elk-distribution-owlapi5, elk-distribution-protege removed modules: - elk-distribution (which has been replaced) - elk-standalone (the ELK CLI standalone binary is now build in elk-distribution-cli) - elk-wolapi-standalone (the ELK OWL API jar package is now build in elk-distribution-owlapi4 and elk-distribution-owlapi5)
|
OK, ELK now supports both OWL API v. 4.x and v.5.x. To use, first add the snapshot repository: For OWL API 4.x use this dependency: For OWL API 5.x use this dependency: Please test and report if there are any problems! |
|
This is awesome! I tested both, and I did not have any problems so far. The getReasonerVersion bug is still there, but I will mention it in the appropriate place. This can be closed I think! |
|
Just a note for anyone who needs to get this working with Groovy, before the full version is released: @Grapes([
@Grab(group='net.sourceforge.owlapi', module='owlapi-api', version='5.1.4'),
@Grab(group='net.sourceforge.owlapi', module='owlapi-apibinding', version='5.1.4'),
@Grab(group='net.sourceforge.owlapi', module='owlapi-impl', version='5.1.4'),
@Grab(group='net.sourceforge.owlapi', module='owlapi-parsers', version='5.1.4'),
@Grab(group='org.apache.commons', module='commons-rdf-api', version='0.5.0'),
@GrabResolver(name='sonatype-nexus-snapshots', root='https://oss.sonatype.org/content/repositories/snapshots/'),
@Grab(group='org.semanticweb.elk', module='elk-owlapi5', version='0.5.0-SNAPSHOT'),
])
` |
|
Hey Yevgeny! As we have a couple of groups now relying on ELK, and the new Snapshot is really awesome, we would be very (!) thankful if you could do a proper Maven central/repository release. There are some issues here and there with inter maven dependencies when something is not actually hosted on one of the known maven repos. :) Greatest thanks, as always! |
|
I am waiting for the next release of Protege (and integration of my pull request protegeproject/protege#734). Without that, the ELK protege plugin does not display warnings properly. Also I wanted to finalise a few things before making the final 0.5 release. This will probably happen only at the end of July - August. |
|
We can wait a bit :)! Thanks for letting me know. We might create our own release, and then replace it once you create an official one. Thank you! |
|
Hey Yevgeny! Any update on our favourite reasoner? :P No, is, of course, fine. As you can see, it is already making waves in GO and UBERON, both of which could not be classified with ordinary OWL 2 reasoners, hence everyone used Elk 0.4.3. But because that was slightly incomplete in terms of axiom types, we get now a few nice issues such as: which references the most exquisite: |
|
So it looks like ELK 0.5 can do more harm than good ;-) |
|
Haha good luck with the semester then! Dont worry for now. The solution you already provided for us is fine in the intermediate time. I will ping you again in December! :) |
|
Which 0.5 dev? The unofficial release of |
|
Yeah we have been using that in curation for a few years now. This one.
…On Tue, 10 May 2022 at 18:48, Yevgeny Kazakov ***@***.***> wrote:
Which 0.5 dev? The unofficial release of au.csiro?
—
Reply to this email directly, view it on GitHub
<#48 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABV6HJ7KEZGEQRZIVVYDG6DVJKALZANCNFSM4EM2IYNQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
OK, could as well name it 0.6. |
|
@ykazakov Happy New Year! Any updates on the Elk 0.6 release? |
|
@matentzn Happy New Year! Yes, I should find some time to finish the ELK release. Will look at it ASAP. |
|
@ykazakov Happy summer :) Hope all is well. Any chance for a.. release this year? Thank you! And i do understand: No time! No problem. Just checking in saying: we are still interested. |
|
FYI: I am planning to change the ELK version and groupId as follows: The version is changed to use more version qualifiers. I think this is now a more modern approach. ;-) I hope these changed do not cause any confusion or disruption. I hope to make a release soon, or at least restore the provision of snapshots from maven central. |
|
I have just re-enabled the snapshot repository. Please test and report if you encounter any problems! |
ykazakov
changed the title
|
@ykazakov thank you! Which changes can we expect in this new release? Is there a new release? Can you make some release notes? Maybe make a proper Github release (even of a pre-release) so we see what to expect. https://github.com/liveontologies/elk-reasoner/releases :) Then we will assign someone for testing! Thank you! Very exciting! |
|
Please post releases to Maven Central to facilitate actually using them. |
|
Hello @ykazakov! We are thinking of updating all our stacks to the new Elk version, but its a bit inconvenient to do it from the snapshot repo without proper versioning. Are there any plans to create a proper Maven release or do you prefer someone else to do it? Also, can we get a list of changes you did for the new version to estimate the impact on our 100 ontologies using Elk during builds? |
|
Hi @matentzn! By all means feel free to create a fork and make the release! Who knows when I have time to work on this again. Particularly, describing all changes made for the last 8 years is not done in an instant. Do you know any automated tool that generates release logs from commits? Also, not sure how would it help to estimate the impact on ontologies - you probably use tons of non-EL features and changes in unsupported cases like #61 would not be described in release log anyway. |
What is nicer though is for projects that consistently use pull requests for all changes, GitHub has a nice feature for auto-generating a changes report from the PRs. You can find that here and then go on to draft a new release. |
|
I agree with @reckart very much :) Thanks @reckart! I would very much endorse doing a github release now so we all know the version we are on. @ykazakov if you like, you can make me a co-owner of this repo and I can do such releases. We can have an understanding that I am not allowed to merge any functional changes to the repo, but having the official ELK repo being "community-driven" would help us immensely while we are evolving our technology stacks. Also, we are having some internal debates how to interpret your new version 5.0.0 - I thought we were in 0.5.0, so I would have thought your new release should be 0.6.0. Can you confirm that? |
|
Thanks @reckart, the git command indeed produces a usable draft. Of course, the list of changes is too long (and a bit cryptic) for release notes. @matentzn doing a (maven) release should not take much time. Everything should be already configured. In principle, I could do a release from the current version on the GitHub in one day. The main problem is to sort the remaining things out. Like the dependency mess caused by the outdated version of Protege (the old versions of Guava and log4j have security vulnerabilities, which you probably do not want to pull together with ELK). I was in a process of fixing these problems, but I had to interrupt. There is also some code in other branches which needs to be merged. I think there is also one snapshot-dependency which should be also released (or removed) for a maven release. Regarding the version number, as mentioned above, being able to use all qualifiers gives more flexibility in choosing versions. I thought you wanted to differentiate from version 0.5.0, which the version 5.0.0 also does. However, if you prefer version 0.6.0, I am also fine with that. How about the following proposal: I make a release of whatever is currently in git under a pre-release version like 0.6.0-rc1, without writing release notes. Would it work for you? |
Ok! Thank you! It would be great if we could get this soon. Can we also create a Github tag with the exact same release version so we can make diffs and comparisons in the future? |
|
@ykazakov if you can make a release that would be great! I had started looking at putting up a release under a different org, but if you are able to do it I think that would be even better. |
|
@ykazakov we have tested your 0.6-SNAPSHOT in Protege and ROBOT and it seems to fix the issues we had with 0.5. Thanks for making that release! Is it possible to put the same release on Maven Central as 0.6.0, or as an RC? |
|
@balhoff Excellent! I decided to make a proper release (not RC). Currently fixing last problems. I hope I can publish to Maven Central this week. Will let you know! |
|
Hey @ykazakov just to let you know the OBO community its holding its breath waiting for your release :P :
(and probably more projects). Since we have thoroughly tested last weeks SNAPSHOT, can you tell us:
|
|
Hi @matentzn @balhoff I am very sorry for the delay. There have been a few last-minute issues that stopped me from making the release. The most significant one is that the plugins install via the Protege UI may only contain one jar. And ELK needs to use a shared library puli to provide proof-based explanations. This library cannot be provided just by the proof-explanation plugin since the reasoner should also work without this plugin. I have now (hopefully) fixed this problem by removing references to puli from the reasoning classes. Currently I finishing things up (updating the README etc), I hope I can do the release tomorrow, if nothing else pops up. I hope this answers your first question. Regarding the breaking changes, I do not think there is any, but feel free to check how the latest snapshot is working for you. Note that the grouId has changed to |
|
So, I just released ELK 0.6 to maven central. I hope it should be available soon (if not already). I will publish the artifacts on github later. |
|
Aweeesome! Thank you! |
|
Thanks @ykazakov! |
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).
The text was updated successfully, but these errors were encountered: