On Thu, 2010-12-30 at 14:20 -0500, Benson Margulies wrote: 
> The examples on http://jena.sourceforge.net/inference/index.html
> 
>  look like:
> 
> (rdfs)
> 
> Model schema = FileManager.get().loadModel("file:data/rdfsDemoSchema.rdf");
> Model data = FileManager.get().loadModel("file:data/rdfsDemoData.rdf");
> InfModel infmodel = ModelFactory.createRDFSModel(schema, data);
> 
> or
> 
> (owl)
> 
> Model schema = FileManager.get().loadModel("file:data/owlDemoSchema.owl");
>     Model data = FileManager.get().loadModel("file:data/owlDemoData.rdf");
>     Reasoner reasoner = ReasonerRegistry.getOWLReasoner();
>     reasoner = reasoner.bindSchema(schema);
>     InfModel infmodel = ModelFactory.createInfModel(reasoner, data);
> 
> In the OWL case, at least, I am wondering about the relationship of
> this to calling createOntologyModel(OntModelSpec.OWL_MEM_xxx);
>  followed by loading both the ontology and the data into the model.

There's two approaches to combining a reasoner, some ontology data and
some instance data.

The first is to just pile that ontology and instance data into a model
(whether an OntModel or a plain model) and attach a reasoner to the
model. This is just fine and is what you would get with the latter
approach.

The second approach is to "bind" the ontology into a reasoner to
generate a specialized reasoner that has the ontology baked in.  The
idea being that in some cases you want to reason with the same ontology
over multiple different sets of instance data. So the reasoner might be
able to do some work for the ontology once and reuse on each set of
instance data. That's that the bindSchema approach supports.

However, given the lack of robust ontology/instance data separation with
OWL/RDFS, and given the current reasoners, the amount of prework that
bindSchema can do is pretty minimal and there is rarely much benefit to
using it. No harm but little benefit.

In the future there may be reasoners which flatten the ontology into an
efficient set of rules (or SPARQL constructs) and which treat the
instance data as pure instance data ignore additional tbox statements.
In that case the bindSchema set would be much more substantial and the
cost savings if you want to apply it to multiple instance models much
greater. We had an experimental reasoner like that once but it is not in
the code base right now.

Dave


Reply via email to