Jena reasoners incremental?

[Tim Harsch <ha...@yahoo.com>]

When I read the docs for Jena2 Inference Support I found the following.  It says "one set of data (typically some schema definitions) to be efficiently applied" (see below).  Does this mean that if your data and ontology were in one file, with the ontology at the end, that you would still end up with the same inferences as in the case where they were mixed in one file with the ontology defined at the beginning?  But that it would be a performance hit?  If so, why?

Applying a reasoner to data
Once you have an instance of a reasoner it can then be attached to a set of RDF data to create an inference model. This can either be done by putting all the RDF data into one Model or by separating into two components - schema and instance data. For some external reasoners a hard separation may be required. For all of the built in reasoners the separation is arbitrary. The prime value of this separation is to allow some deductions from one set of data (typically some schema definitions) to be efficiently applied to several subsidiary sets of data (typically sets of instance data).
If you want to specialize the reasoner this way, by partially-applying it to a set schema data, use the Reasoner.bindSchema method which returns a new, specialized, reasoner.
To bind the reasoner to the final data set to create an inference model see the ModelFactory methods, particularly ModelFactory.createInfModel.


      

Re: Jena reasoners incremental?

[Dave Reynolds <da...@gmail.com>]

On Tue, 2011-03-01 at 09:59 -0800, Tim Harsch wrote: 
> When I read the docs for Jena2 Inference Support I found the following.  It says "one set of data (typically some schema definitions) to be efficiently applied" (see below).  Does this mean that if your data and ontology were in one file, with the ontology at the end, that you would still end up with the same inferences as in the case where they were mixed in one file with the ontology defined at the beginning?  But that it would be a performance hit?  If so, why?

The key part of the section you quoted is "... to several ...";

If you have one pile of data containing a mix of tboxy stuff and aboxy
stuff there's no benefit in separating it, at least as far as driving
the current Jena rule reasoners is concerned. In fact there will be a
very small extra cost for doing the bindSchema step separately from
applying to the data.

The situation bindSchema is aimed at is where you are, over time, going
to get a sequence of abox models and you want to reason over each of
them using the same fixed background ontology. In that case building a
specialized reasoner that already knows about the ontology and then
applying that to each data model as it comes in can lead to some
savings. Some of the reasoning over the schema itself is done once then
reused.

In practice, for the current Jena rule sets, the performance difference
is probably fairly modest.

However, for other reasoners that partial application step could make a
bigger difference. For example, we [*] did have a configuration that
compiles an ontology into a set of grounded forward rules that could run
pretty efficiently on subsequent abox-only data sets.

Dave

[*] we = mostly Chris

> Applying a reasoner to data
> Once you have an instance of a reasoner it can then be attached to a set of RDF data to create an inference model. This can either be done by putting all the RDF data into one Model or by separating into two components - schema and instance data. For some external reasoners a hard separation may be required. For all of the built in reasoners the separation is arbitrary. The prime value of this separation is to allow some deductions from one set of data (typically some schema definitions) to be efficiently applied to several subsidiary sets of data (typically sets of instance data).
> If you want to specialize the reasoner this way, by partially-applying it to a set schema data, use the Reasoner.bindSchema method which returns a new, specialized, reasoner.
> To bind the reasoner to the final data set to create an inference model see the ModelFactory methods, particularly ModelFactory.createInfModel.
> 
> 
>