GenericRuleReasoner.filterFunctors doesn't apply to InfModel.getDeductionsModel ?

[Joshua TAYLOR <jo...@gmail.com>]

Hi all,  I don't think this is a bug, strictly speaking, but it's a
behavior that surprised me a bit, and I'd like to check that it's
expected.  In the Jena 2 Inference Support [1] document, there's this
description of InfModel.getDeductionsModel:

""" Some reasoners, notably the forward chaining rule engine, store
the deduced statements in a concrete form and this set of deductions
can be obtained separately by using the getDeductionsModel() call.
""""

In the description of getDeductionsModel from the InfModel Javadoc:

""" Model getDeductionsModel() --- Returns a derivations model. The
rule reasoners typically create a graph containing those triples added
to the base graph due to rule firings. In some applications it can
useful to be able to access those deductions directly, without seeing
the raw data which triggered them. In particular, this allows the
forward rules to be used as if they were rewrite transformation rules.
"""

Finally, from the description of GenericRuleReasoner [3], particular,
for filterFunctors and setFunctorFiltering,

""" public boolean filterFunctors --- Flag, if true then find results
will be filtered to remove functors and illegal RDF ...
public void setFunctorFiltering(boolean param) --- Set to true to
cause functor-valued literals to be dropped from rule output. Default
is true. """

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?  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...)

Thanks in advance,
//JT

[1] http://openjena.org/inference/#RULEbuiltins
[2] http://incubator.apache.org/jena/documentation/javadoc/jena/com/hp/hpl/jena/rdf/model/InfModel.html#getDeductionsModel%28%29
[3] http://incubator.apache.org/jena/documentation/javadoc/jena/com/hp/hpl/jena/reasoner/rulesys/GenericRuleReasoner.html#setFunctorFiltering%28boolean%29
-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/

Re: GenericRuleReasoner.filterFunctors doesn't apply to InfModel.getDeductionsModel ?

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

On 22/02/12 18:56, Joshua TAYLOR wrote:
>
> 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?

Ah yes, should have remembered that.

Definitely you should remove the Triples with literals as subjects since 
those aren't syntactically valid RDF Statements (fine for Graph/Triple 
but not fine for Model/Statement).

For the hidden nodes you might not need to do this, depending on what 
your goals are. Some of the rules use particular predicates for 
representing useful intermediate information which don't necessarily 
help consumers of the results. E.g. the XSD rules record the base xsd 
type for any derived XSD type. The "hide" directive is used to request 
those be filtered out.

Dave

Re: GenericRuleReasoner.filterFunctors doesn't apply to InfModel.getDeductionsModel ?

[Joshua TAYLOR <jo...@gmail.com>]

On Wed, Feb 22, 2012 at 10:50 AM, Dave Reynolds
<da...@gmail.com> 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/

Re: GenericRuleReasoner.filterFunctors doesn't apply to InfModel.getDeductionsModel ?

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

On 22/02/12 15:18, Joshua TAYLOR wrote:
> Hi all,  I don't think this is a bug, strictly speaking, but it's a
> behavior that surprised me a bit, and I'd like to check that it's
> expected.

[clear explanation snipped]

> 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.

> 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.

Dave