[Pellet-users] Questions on Modifying the Pellet KB from Jena

[Michael Smith]

On Thu, 2007-06-21 at 13:40 +0200, Paolo Bussotti wrote:

> I've seen that, if directly use the KB methods to change the KB 
> (addIndividual, etc..), then when I test the status of the KB via 
> isChanged() it returns true, as expectable, and when I call getInfo() it 
> responds correctly with the changes made.

isChanged() indicates that there have been changes to at least one of
the A-Box, T-Box, or R-Box since the most recent prepare() calls.  Most
methods manipulating the KB internals, including getInfo(), will call
prepare() as needed.

> But, in my current project, I change the KB through a Jena Pellet-backed 
> OntModel (and so I cannot get incremental reasoning) and what I'd like 
> to know is this:
> If I make a change to the model (e.g. add an Individual) through the 
> Jena methods, then create the PelletInfGraph and prepare it, I think 
> that the whole graph underlying the model of the ontology and its 
> imports is sent to the OWLReasoner and KnowledgeBase (correct me if I'm 
> wrong, please).

You are correct.

> When I get the KB by calling the getKB() method on the prepared 
> PelletInfGraph, and then call getInfo() then the change in the KB (e.g. 
> a new individual) is shown as happened. But if I call isChanged() it 
> return false.

If prepare() was called on the graph, it caused a kb.prepare() and the
change status was reset.

> This, according to me, is due to the fact that a clear() 
> operation followed by a complete reloading is non considered as a 
> change, is simply a new knowledgebase content.
> In each case I can work with it, cheching consistency after changes and 
> so on, even if performances are obviously low.
> In particular I've understood from the list that the fact that 
> PelletInfGraph.prepare() clears and reloads everything (and not just add 
> the differences) is due to the particular implementation of Jena bindings.

Not quite. Any graph that has changed is reloaded.  If all graphs have
changed (the case unless you have been using a MultiUnion), the kb is
cleared and reloaded.  This is recognized as a change.

It is the graph prepare() (and the consequent kb.prepare()) that cause
the change status to be reset.

> Might you, please, correct me If I asserted something wrong and/or 
> provide some additional details?

It's unclear how the details above are useful to you.  I suspect there
may have been confusion regarding the semantics of the isChanged()
method, feel free to follow up in any case.
-- 
Mike Smith

Clark & Parsia