Hello,
Thought I'd give a quick suggestion for the SPIN API. The spin:rule
based inferencing is a very powerful way to assign inference rules to
classes in an object oriented way. However, as currently implemented
it's pretty much an all or nothing way to create and add inferred
triples to a single model. This is because spin:rule is hardcoded in
the SPINInferences.run function and at runtime all of a class's
specified spin:rule's (or subproperties thereof) are exectued en-mass,
with all inferred triples added to the single 'newTriples' model:
public static int run(
Model queryModel,
Model newTriples,
SPINExplanations explanations,
List<SPINStatistics> statistics,
boolean singlePass,
ProgressMonitor monitor) {
Map<QueryWrapper, Map<String,RDFNode>>
initialTemplateBindings = new HashMap<QueryWrapper,
Map<String,RDFNode>>();
Map<Resource,List<QueryWrapper>> cls2Query =
SPINQueryFinder.getClass2QueryMap(queryModel, queryModel, SPIN.rule,
true, initialTemplateBindings, false);
return run(queryModel, newTriples, cls2Query,
initialTemplateBindings, explanations, statistics, singlePass, monitor);
}
To make this powerful capability more flexible, what I've done is
re-create the run function with the rule predicate being parameterized.
public int runSPINInferences(
Model queryModel,
Model newTriples,
Property rulePredicate ,
SPINExplanations explanations,
List<SPINStatistics> statistics,
boolean singlePass,
ProgressMonitor monitor) {
Map<QueryWrapper, Map<String,RDFNode>>
initialTemplateBindings = new HashMap<QueryWrapper,
Map<String,RDFNode>>();
Map<Resource,List<QueryWrapper>> cls2Query =
SPINQueryFinder.getClass2QueryMap(queryModel, queryModel, rulePredicate,
true, initialTemplateBindings, false);
return SPINInferences.run(queryModel, newTriples,
cls2Query, initialTemplateBindings, explanations, statistics,
singlePass, monitor);
}
This way I can create sibling subproperties of spin:rule, and in my
SPARQL engine I can pick and choose exactly which rules get run based on
the current state/progress of the engine, as well as specify the model
to be updated with the "inferred" triples based on the type of rule
being executed. For example, I've setup two subproperties of spin:rule
SpinLib:inferenceRule
SpinLib:transformRule
Our SPARQL engine first runs all the SpinLib:inferenceRule's, which adds
all the triples back into the source model:
runSPINInferences(baseModel, baseModel, inferenceRule, exp, null, true,
null);
These are for rules like calculating the area of a rectangle based on
height and width.
After these new triples are created, the engine then runs transform
rules on the source model.
runSPINInferences(baseModel, destModel, transformRule, exp, null, true,
null);
For these transforms the triples are added to the model being
transformed into destModel), and not back into the source model.
Anyway, it was a very simple change for me to make locally, but thought
perhaps allowing this flexibility might be something you might want to
consider adding directly to the API (and/or perhaps more importantly
documenting the capability/pattern). Perhaps some typical subproperties
could even be added to the spin model. I would think model transforms
such as we're using would be a very useful and general type of inference
that people could use. Also seems like something that might be able to
be combined with SPARQLMotion in some way to allow transforms to be a
little more object-oriented (e.g. the classes transform themselves).
Btw, is this the proper forum for SPIN API questions/comments?
Thanks,
Jeff
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TopBraid Composer Users" group.
To post to this group, send email to topbraid-composer-users@googlegroups.com
To unsubscribe from this group, send email to
topbraid-composer-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---
