On Apr 6, 2011, at 5:38 PM, Gerrit wrote:
> It looks like the SPIN API performs a lock while reasoning, and has to
> do this multiple times in order to perform all the inferments that is
> produced by adding topbraid/spin/owlrl-all and topbraid/spin/owlrl.
I am not aware of the SPIN API performing a lock. Do you have any insights as
to which Java methods would do this?
>
> Adding just those two files to the model creates 10491 inferred
> triples. Is this the kind of behavior I should expect when using SPIN
> rules to infer OWL2 RL?
This depends on your set-up, i.e. how you invoke the inference engine. If you
just put all triples including the OWL RL models into the same Jena Model, then
the system will run inferences over all triples, including the OWL RL ontology,
SPIN system triples etc. This will include a lot of uninteresting inferences
and slow down the whole process.
What I usually do is to create a Jena OntModel / MultiUnion graph that has the
domain ontology as base graph, and the OWL RL models and other rule bases as
"imports". Then it's possible to build up a complete list of available rules,
and put it into a HashMap that is used as input to the actual inferencing step.
The following code (from SPINInferences.run()) shows how to get those rules
Map<CommandWrapper, Map<String,RDFNode>>
initialTemplateBindings = new HashMap<CommandWrapper, Map<String,RDFNode>>();
Map<Resource,List<CommandWrapper>> cls2Query =
SPINQueryFinder.getClass2QueryMap(queryModel, queryModel, rulePredicate, true,
initialTemplateBindings, false);
Map<Resource,List<CommandWrapper>> cls2Constructor =
SPINQueryFinder.getClass2QueryMap(queryModel, queryModel, SPIN.constructor,
true, initialTemplateBindings, false);
SPINRuleComparator comparator = new
DefaultSPINRuleComparator(queryModel);
return run(queryModel, newTriples, cls2Query, cls2Constructor,
initialTemplateBindings, explanations, statistics, singlePass, rulePredicate,
comparator, monitor);
Then, the queryModel itself can be a sub-set of the whole union model. It could
simply be the base model that you want to query. TopSPIN usually does this as
well, and uses all spin:LibraryOntologies to collect the rules (and
constraints) only, but ignores them in the query model. This way, you can even
pre-compute all rules once and keep them in a HashMap for the life time of your
application.
I will try to clarify this with a fully worked out example for the next SPIN
API release, but the ideas above may point you in the right direction in the
meantime.
Regards,
Holger
--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
