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.

[ignazio1977]

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.

[ykazakov]

I think I have some explanation regarding the thrown java.lang.NoSuchMethodError When I try to print the method getProperty() for OWLTransitiveObjectPropertyAxiom using the following code:

Class<?> cls = OWLTransitiveObjectPropertyAxiom.class;
Method method = cls.getMethod("getProperty", (Class<?>[]) null);
System.out.println(method);

For OWL API 4.5.1 this gives me:

public abstract org.semanticweb.owlapi.model.OWLPropertyExpression org.semanticweb.owlapi.model.OWLUnaryPropertyAxiom.getProperty()

For OWL API 5.1.4 I obtain:

public abstract org.semanticweb.owlapi.model.OWLObject org.semanticweb.owlapi.model.HasProperty.getProperty()

Notice the different return types: OWLObject instead of OWLPropertyExpression. Why? Because in OWL API 4 OWLUnaryPropertyAxiom overrides getProperty() from the generic super-interface HasProperty<P> to return OWLPropertyExpression (the smallest type of the generic parameter), but in OWL API 5 it is not overriden. So, when ELK is compiled against OWL API 4, in the byte code of ELK where the method OWLTransitiveObjectPropertyAxiom.getProperty() is invoked, it is written that the returned value should be of the type OWLPropertyExpression, and this is not the case for OWL API 5! Note that the generic parameters have no effect on the byte code!

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 OWLObject of getProperty() compiled in the byte code is more general than OWLPropertyExpression present in the library. It is not clear whether this compatibility holds in other cases though, so further tests are necessary.

So to sum up: binary compatibility is a very tricky issue.

[ignazio1977]

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?)

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?

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.

[ykazakov]

FYI: here I found a small utility that can check compatibility of jars and compared owlapi-api-5.1.0.jar with owlapi-api-5.1.4.jar.

Here is the result:

Binary compatibility: 99.8%
Source compatibility: 96.8%

=> so not 100% compatible.

The full report can be seen here.

[ykazakov]

OK, ELK now supports both OWL API v. 4.x and v.5.x. To use, first add the snapshot repository:

<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>

For OWL API 4.x use this dependency:

<dependency> 
   <groupId>org.semanticweb.elk</groupId> 
   <artifactId>elk-owlapi4</artifactId> 
   <version>0.5.0-SNAPSHOT</version> 
</dependency> 

For OWL API 5.x use this dependency:

<dependency> 
   <groupId>org.semanticweb.elk</groupId> 
   <artifactId>elk-owlapi5</artifactId> 
   <version>0.5.0-SNAPSHOT</version> 
</dependency> 

Please test and report if there are any problems!

[matentzn]

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!

[reality]

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'),
  ])
`

[matentzn]

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!

[ykazakov]

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. If you urgently need ELK from Maven central, or at least its OWL-API artefacts, I suggest to release them yourself. If you release them under your groupId, this should not confuse the users of "official" releases.

[matentzn]

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!

[matentzn]

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:

• https://github.com/ontodev/robot/issues/380

which references the most exquisite:

• https://github.com/geneontology/go-ontology/issues/16524 and
• https://github.com/obophenotype/uberon/issues/1455

[ykazakov]

So it looks like ELK 0.5 can do more harm than good ;-) Unfortunately, I did not have much time to work on ELK this summer. Now as semester has started this will be even more difficult. Perhaps I can release the current version to maven-central as 0.5-beta1 or something, perhaps in a few weeks.

[matentzn]

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! :)

[bjonnh]

Any update on that?

[ykazakov]

@bjonnh unfortunately not.

[matentzn]

@ykazakov From your perspective, do you think ELK will ever be funded/developed again? So much is relying on it now, and I would just like to plan for a future of Java 11, OWL API 6, etc.. Do you have plans/funds to maintain ELK, or will you ever again? :P Thank you..

[ykazakov]

@matentzn I don't have plans for ELK other than releasing the code that we've been working on for the last 5 years or so. Regarding the maintenance, I do not think there should be much problems. Switching to Java 11, OWL API 6, etc. should not require understanding much of the ELK internals. There haven't been that many bug reports in the past either.

[matentzn]

Ok thanks :) I am asking also because of Sequoia, which promises consequence-based reasoning up to SROIQ, and I just wanted to see whether anything similar is planned for our favourite reasoner :D

Thanks for the info. Do you have a timeline for the release?

[ykazakov]

and I just wanted to see whether anything similar is planned for our favourite reasoner :D

Not for this reasoner. ELK will stick to OWL EL (or at least some polynomial extension thereof)

Do you have a timeline for the release?

I can try to find time in August-September during the semester holidays.

[ignazio1977]

Switching to Java 11, OWL API 6, etc

I'm happy to help with the mechanics of that, when it becomes necessary.

[matentzn]

Hey @ykazakov Hope you are well!

Is it fair to assume that probably you wont continue developing ELK further? Or are there any other plans? We will now add it to maven central ourselves, but I am also wondering about finalising the Protege plugin etc.. Its so hard to explain every time to install the Snapshot version :D

We are probably also going to suggest some fixes (but super minor).

[ykazakov]

@matentzn I just pushed the changes I did over this summer with incompleteness detecting / testing / reporting -- actually tons of changes -- see the branch feature/completeness-monitoring. Unfortunately I did not finish the reporting part yet, and also some cases of incompleteness (e.g., violation of global restrictions) are not detected yet. I know that you probably do not care about incompleteness, but probably you do not want the users to see tons of warning messages. ;-) So this needs to be polished before the release.

I also plan a small optimisation of queries addressing #28, after that I think ELK can finally be released. But feel free to release the current version on maven central for your convenience! I am surprised you haven't done this yet! ;-) Actually, I am probably going to change the group-id anyway since we could not reach the owner of semanticweb.org anymore.

Which Protege plugins are you talking about?

Please do report bugs in the issue tracker.

[matentzn]

This is christmas to hear you say that.. I will comment later more. Best news! :) Thank you!

[matentzn]

Our needs are quite practical:

1) we would like ELK 0.5 (or whatever your new version is called) on maven central - both compatible with OWLAPI 4 and OWL API 5 (we still have too many tools on 4, but many are now on 5). 2) we would like the Protege plugin referenced here in the protege registry (here). We have been using Elk 0.5 across the board, but it was always a bit of a hassle to explain to people how to install it.

We will open a new ticket for any issues separately.

THANK YOU!

[ykazakov]

I cannot promise I can release ELK by Christmas, but as you can see, it is getting closer. ;-) If you could test the current (branch) version and report any (performance) problems compared to the previous released version that would be really helpful! Just to make it clear: you are not interested in new Protege explanations plugins that use the ELK proofs, are you? Because that would require a bit more work to release.

[matentzn]

I did not know you were still working on this! Cool!

I think we can wait for that explanation plugin a while longer - but thanks for reminding me - I will look into that again as well early next year.

Alright, after Christmas then :) - I will keep nagging you though :D

So we have this interesting situation (please prepare yourself :) that we have been using elk 0.4.3 for years across all our pipelines, for ontologies a good deal beyond EL (and what ELK supports). So basically, we were doing approximate, and highly incomplete, reasoning. Now we have started here and there to SWAP out ELK 0.4.3 with 0.5 (for example, recently, OLS). This lead to thousands of previously unknown unsatisfiable classes across dozens of ontologies (mostly due to problems with domain/range constraints of relations, or my favourite axiom responsible for what I would guess accounts for 20% of all unsats: DisjointClasses(part of some occurrent, continuant). We are now trying to clean this up (including @balhoff, @cmungall, @dosumis and me). So yeah, thats where we are at! So the earlier the better for us (noooooo pressure intended :D)

[ykazakov]

@matentzn I have now some time to work on ELK and hopefully to finalise the release. You were mentioning some minor fixes. Can you provide details?

[matentzn]

Hey @ykazakov I have reached out to @balhoff who I believed made some observations, but to be honest, I might misremember this entirely.. It left my consciousness in any case..

[matentzn]

Hey @ykazakov Any updates on a proper Elk 0.5 release on maven central? Would be greatly appreciated! Lots of ontologies rely on you!

[ykazakov]

@matentzn Is there any problem with this unofficial version? I think it was released off the master branch about a year ago, which is not so outdated.

I will try to find some time to work on ELK, but probably after the semester end (end of February).

[matentzn]

No problem, just checking; I am waiting for a proper maven release (were I can advice collaborators to switch 0.4.3 in the pom.xml without adding temporary repositories and the risk that behaviour of the reasoner will change at release time) because there are dozens of code bases we need to migrate - hundreds of integration tests to be run etc. for example, Gene Ontology plus right now has a good number of unsatisfiable classes because of ELK 0.5 advanced range reasoning. The migration from one reasoner to another is just too costly for us to migrate to a temporary intermediate. We will eagerly wait. :)

[ykazakov]

This seems like a use case for a common parent pom with a proper <dependencyManagement>. If you migrate from ELK 0.5 to say ELK 0.5.1 you will have the same problem! Or if you need to patch log4j in all your projects. ;-)

[matentzn]

Yeah, this is why I want to wait for whatever you consider the next major version! I do not want to go through this process twice, and since you are working on ELK, I feel its better to wait until that work is done.. Dont worry, I am not trying to push anything, just checking in and making plans! :) Thanks for the update!

[ykazakov]

Please do not wait but test and report problems! How else the stable version would appear if everyone is waiting? I cannot possibly test all your use cases!

[matentzn]

Dont worry, we have been using the ELK 0.5 protege plugin for many moons. I will see what I can do getting a test version of ROBOT up with Elk 0.5.

[balhoff]

@ykazakov are there some issues we should be looking out for? Nico has a small army of people using the Protégé plugin and I don't recall hearing of any problems at all so far. 🙂