On 13/07/12 07:58, Jan Schäfer wrote:
Hi Dave,
thank you for your answer. I'll comment below:
Am 12.07.2012 22:50, schrieb Dave Reynolds:
You'll have to ask on the Pellet list for such hints.
I tried that before posting here, but so far no reaction.
It's common in other reasoners to be able to process additions
incrementally (because the semantics
is monotonic) but to process a remove you often have to just start
over from scratch. Hence the
asymmetry in speed.
I thought that could be the reason but found it strange that the
reasoner is able to process the models much faster when it's run first
(or in Protege) compared to the update after individual removal.
That is very strange. I would have expected rebind to be identical to
starting with a fresh model. I wonder if the fact that you have changed
the data "behind the reasoners back" is upsetting it.
You could always try creating a new InfModel over the same base model in
place of the rebind. If that's also slow then that suggests there is
something problematic about the specific post-changes data.
Normal practice to do do changes through the infModel rather than
through the base model. In that
case you don't need to do a rebind. It is up to the reasoner to decide
when to process the changes.
The reason I chose to do changes behind the reasoner's back was that I
thought it might be better to be able to decide myself when to let the
inference model know about changes. I'll have to think about my approach
now.
Yes, there's nothing wrong with your approach. Having control yourself
is good. The potential trouble with rebind is that it is telling the
reasoner to start over and so defeats any incremental processing
options. But it certainly shouldn't be slower than starting over afresh.
Dave
