search

owlcs / owlapi

OWL API main repository
825 stars 314 forks source link

`uk.ac.manchester.cs.owl.owlapi.Internals` should become again interface-based like it used to be in Version 3 #1108

Open twwwt opened 1 year ago

twwwt commented 1 year ago

In the older version 3.2 of the OWL API there used to be an interface uk.ac.manchester.cs.owl.owlapi.Internals, having a (standard) implementation uk.ac.manchester.cs.owl.owlapi.InternalsImpl (actually indirectly via uk.ac.manchester.cs.owl.owlapi.AbstractInternalsImpl).

In Version 5.5 however, uk.ac.manchester.cs.owl.owlapi.Internals is now a class, and the interface is gone (I haven't checked when this refactoring was actually introduced).

This makes it more complicated to create alternative OWLOntology implementations. More precisely, I'm in the process of refactoring an implementation (for more background see below) from version 3.2 to the latest version 5.5. In the old version, the alternative OWLOntology implementation was extending uk.ac.manchester.cs.owl.owlapi.OWLOntologyImpl and it was possible to set an alternative Internals implementation in its constructor. Now, using version 5.5, one needs to go further up the class inheritance hierarchy and needs to extend uk.ac.manchester.cs.owl.owlapi.OWLObjectImpl. For reference, this is the relevant part of the current class hierarchy:

uk.ac.manchester.cs.owl.owlapi.OWLOntologyImpl extends
uk.ac.manchester.cs.owl.owlapi.OWLImmutableOntologyImpl extends
uk.ac.manchester.cs.owl.owlapi.OWLAxiomIndexImpl extends // has Internals field, which is final
uk.ac.manchester.cs.owl.owlapi.OWLObjectImpl

It is no longer possible to directly extend uk.ac.manchester.cs.owl.owlapi.OWLOntologyImpl since it derives the final Internals from OWLAxiomIndexImpl (by doing so, one would instantiate the standard Internals for nothing and it would not be used). As a result, one needs to extend OWLObjectImpl now, which in turn results in the need to re-implement all the other methods that OWLAxiomIndexImpl and OWLImmutableOntologyImpl implement. This is essentially repeated code. It would make more sense to re-use/derive it by extending at least OWLAxiomIndexImpl. Or even better by extending OWLImmutableOntologyImpl if this implementation would, in addition, also allow to enable/disable its internal caches (LoadingCache).

What do you think?

Background: Quite some time ago, I've created an alternative OWLOntology implementation that supports concurrent access (i.e., instances may be shared by more than one Java thread). Rather that MRSW locking (as it is used by uk.ac.manchester.cs.owl.owlapi.concurrent.ConcurrentOWLOntologyImpl), this implementation is based on Snapshot Isolation to coordinate concurrent access. Snapshot Isolation provides much better performance than locking under higher contention (note, however, that standard Snapshot Isolation is not equivalent to a serial execution). This implementation was created as part of my PhD and I thought to resurrect it and release it as Open Source as an extension to the OWL API.

ignazio1977 commented 5 months ago

I don't know snapshot isolation but if your code is available somewhere I'd love to learn. Current locking implementation has a number of limitations and a replacement would be good to have.

twwwt commented 5 months ago

Not yet. I was on the way of refactoring it to become compatible with version 5.5 of the OWL API. At the time I was developing it, version 3 was the current one. Meanwhile, the internals of the OWL API have changed a lot and I had to realize that a lot of changes have to be made. Resolving the request described by this issue would help a lot to reduce this effort. Since the creation of this issue I have essentially not made progress.

But as I said, this whole effort was initiated to publish it eventually as Open Source, because I think it would really be a valuable extension to the OWL API.