On Wed, Feb 22, 2012 at 10:50 AM, Dave Reynolds
<[email protected]> wrote:
> On 22/02/12 15:18, Joshua TAYLOR wrote:
>> However, it seems that while queries to an InfModel or OntModel backed
>> by a GenericRuleReasoner filter out functors, and functors don't
>> appear when an OntModel is written with OntModel.writeAll, the Model
>> returned by InfModel.getDeductionsModel includes the functors,
>> regardless of the value of filterFunctors. I don't know whether the
>> Model returned by getDeductionsModel should be considered as part of
>> "the results" from which functors should be filtered or not, but not
>> filtering functors from getDeductionsModel certainly does make the use
>> of "forward rules ... as if they were rewrite transformation rules"
>> more complicated.
>>
>> So, is this the expected behavior?
>
> Yes.
>
> Whether it's the *right* design is questionable :) but it is, at least, a
> long standing "feature".
>
> The basic thinking was that the deductions model is a faithful
> representation of the state derived by the rules. Any filter to hide stuff
> is the responsibility of the wrapping InfModel. There are times, not least
> during debugging, when the ability to see the exact deductions state is
> helpful.
Thanks for the quick and detailed response! I can certainly see the
benefit of having the functors in the deductions model (and will
probably be very thankful for it pretty soon).
>> Is there an easy way to filter
>> functors from the deductions model? (I see that there is
>> Functor.acceptFilter, and that might be a start...)
>
> You could create a simple Graph implementation based on WrappedGraph which
> overrides the find operation to introduce
> filterDrop(Functor.acceptFilter)
> on the result iterator. Then you can create a filtered deductions model by
> getting the graph, wrapping it with the graph filter and embedding it back
> in the same context.
Your comment above that any filtering is the responsibility of the
InfModel (or the InfGraph, it seems) made me wonder why the reasoner
has a filterFunctors field*. Seeing how filterFunctors is used in the
the reasoner's bind method answered that, though, and got me looking
into the implementation of the various InfGraphs, some of which do
more filtering than just removing functors. For instance,
FBRuleInfGraph's findWithContinuation method includes
if (filterFunctors) {
// return result.filterDrop(Functor.acceptFilter);
return result.filterDrop( new Filter<Triple>() {
@Override public boolean accept( Triple o )
{ return FBRuleInfGraph.this.accept( o ); }} );
and the commented return line makes me wonder if removing the functors
from an InfModel's deductions model might still have some invalid RDF
around (e.g.., triples with literals as subjects, and hidden nodes
(I'm not sure where hidden nodes are used, but FBRuleInfGraph.accept
filters them out)). Is this something I'd need to worry about while
implementing a WrappedGraph using the recommended techniques?
Many thanks,
//JT
* A coworker and I had a great time talking about false filterFunctors
flag fields.
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
