You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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) implementationuk.ac.manchester.cs.owl.owlapi.InternalsImpl
(actually indirectly viauk.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 alternativeOWLOntology
implementation was extendinguk.ac.manchester.cs.owl.owlapi.OWLOntologyImpl
and it was possible to set an alternativeInternals
implementation in its constructor. Now, using version 5.5, one needs to go further up the class inheritance hierarchy and needs to extenduk.ac.manchester.cs.owl.owlapi.OWLObjectImpl
. For reference, this is the relevant part of the current class hierarchy:It is no longer possible to directly extend
uk.ac.manchester.cs.owl.owlapi.OWLOntologyImpl
since it derives the finalInternals
fromOWLAxiomIndexImpl
(by doing so, one would instantiate the standardInternals
for nothing and it would not be used). As a result, one needs to extendOWLObjectImpl
now, which in turn results in the need to re-implement all the other methods thatOWLAxiomIndexImpl
andOWLImmutableOntologyImpl
implement. This is essentially repeated code. It would make more sense to re-use/derive it by extending at leastOWLAxiomIndexImpl
. Or even better by extendingOWLImmutableOntologyImpl
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 byuk.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.The text was updated successfully, but these errors were encountered: