You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Nouwt, B. (Barry)" <ba...@tno.nl> on 2018/01/16 09:55:58 UTC
GenericRuleReasoner with limited scope
Hi everyone,
Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
Note:
* I am willing to accept some incomplete answers to get the functionality described in 1.
* In literature I found the term 'query answering' as one of the things a reasoner can do, which looks like the behavior I describe in point 1 above. It is also mentioned here: http://ontogenesis.knowledgeblog.org/1486
Does anyone know whether the behavior described above is possible (does Apache Jena allow the reasoner to use the SPARQL query as input at all) and whether there are rule engine implementations for Jena available that implement such behavior? Is it possible to configure Jena in such a way that it restarts the reasoner for every query it receives?
Any other pointers that help me understand this reasoner related subject are welcome as well.
Regards,
Barry
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
RE: GenericRuleReasoner with limited scope
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl>.
Just to confirm; using backward syntax for rules works as expected.
However, it is still not clear if and if so, how, you can configure ruleMode=BACKWARD via an Assembler file in Fuseki.
Thanks for all the help.
Barry
-----Original Message-----
From: Nouwt, B. (Barry) [mailto:barry.nouwt@tno.nl]
Sent: vrijdag 19 januari 2018 13:21
To: users@jena.apache.org
Subject: RE: GenericRuleReasoner with limited scope
Hi Dave,
You are right, I assumed unknown URIs would be ignored (but aren't [1]) and unknown values for URIs were not (which is true [2]).
I'll try the backward syntax tip, thanks!
Barry
[1] https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/FBRuleReasoner.java#L346
[2] https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/GenericRuleReasoner.java#L306
-----Original Message-----
From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
Sent: vrijdag 19 januari 2018 11:38
To: users@jena.apache.org
Subject: Re: GenericRuleReasoner with limited scope
Hi Barry,
I don't understand the assembler syntax enough to directly help (no doubt others can) but given you didn't get any error messages when you had the wrong URI then not getting an error message from "bla" isn't definitive :)
As mentioned your other alternative is to leave the reasoner in hybrid mode and write your rules in backward syntax.
Dave
On 19/01/18 09:49, Nouwt, B. (Barry) wrote:
> Hi all,
>
> I fixed the error Dave found, but it does not seem to activate
> 'backward' mode. I test it by providing a wrong value 'bla' instead of
> 'backward' and check whether Fuseki fails to load the assembler. But,
> unfortunately, it doesn't fail.
>
> Any other suggestions on how to enable 'backward' mode from an
> assembler file?
>
> Regards, Barry
>
> Verzonden vanaf mijn Windows 10-telefoon
>
> *Van: *Dave Reynolds <ma...@gmail.com>
> *Verzonden: *donderdag 18 januari 2018 09:40
> *Aan: *users@jena.apache.org <ma...@jena.apache.org>
> *Onderwerp: *Re: GenericRuleReasoner with limited scope
>
> Hi Barry,
>
> I'm not sure of the assembler syntax but there's one error in your
> example which might fix it:
>
> > @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
>
> That should be:
>
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner#> .
>
> Dave
>
> On 17/01/18 15:12, Nouwt, B. (Barry) wrote:
>> Hi Dave, thanks for the answer.
>>
>> I was not aware that the backward reasoner started at triple patterns (retrieved from the SPARQL query), so I will definitely test whether that indeed causes the rule to be applied once instead of twice in the example described in my second post.
>>
>> My setup uses Apache Jena Fuseki, so the PROPruleMode should be
>> configured via a assembly TTL file. Do you know how to do that? I
>> found the 'http://jena.hpl.hp.com/2003/RuleReasoner/ruleMode'
>> property in the
> ReasonerVocabulary.java file [1], but it does not seem to load this
> property when I use the following assembly:
>>
>> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
>> .
>> .
>> .
>>
>> <#infGraph> rdf:type ja:InfModel ;
>> ja:reasoner [ ja:rulesFrom
>><file:src/test/resources/et.rules> ;
>> rr:ruleMode "backward" ; ] ;
>> ja:content <#test-inf> .
>>
>>
>> Any pointers are welcome!
>>
>> Regards, Barry
>>
>> [1]
>> https://github.com/apache/jena/blob/cc038809fb622779933831011909714e2
>> 2ef494c/jena-core/src/main/java/org/apache/jena/vocabulary/ReasonerVo
>> cabulary.java#L77
>>
>> -----Original Message-----
>> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
>> Sent: woensdag 17 januari 2018 09:33
>> To: users@jena.apache.org
>> Subject: Re: GenericRuleReasoner with limited scope
>>
>> On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
>>> Hi everyone,
>>>
>>> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>>>
>>> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>>>
>>> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
>>> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
>>
>> If I understand what you want then use the backward rather than forward engine.
>>
>> The GenericRuleReasoner contains two engines which can be used
>> separately or in a cascade (hybrid mode). For configuring this see
>> PROPruleMode in
>> https://jena.apache.org/documentation/inference/#RULEconfiguration
>>
>> The backward reasoner is driven by goals at the level of triple patterns and isn't aware of the overall sparql query so the goals are not very selective but it will at least help with point #1.
>>
>> In terms of point #2 then the backward engine, by default, will not retain any answers. You can use the tabling declarations to cause it to selectively remember the answer to specific (sub)goals if you need to see:
>> https://jena.apache.org/documentation/inference/#RULEbackward
>>
>> Note that in hybrid mode (the default) you can still use backward rules by writing them with the arrow reversed. The advantage of switching the reasoner mode is that you can use the same rule source syntax and run the rules in either forward or backward mode to test the difference.
>>
>> Dave
>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by
>> mistake, you are requested to inform the sender and delete the
>> message. TNO accepts no liability for the content of this e-mail,
>> for the manner in which you use it and for damage of any kind
> resulting from the risks inherent to the electronic transmission of
> messages.
>>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
RE: GenericRuleReasoner with limited scope
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl>.
Hi Dave,
You are right, I assumed unknown URIs would be ignored (but aren't [1]) and unknown values for URIs were not (which is true [2]).
I'll try the backward syntax tip, thanks!
Barry
[1] https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/FBRuleReasoner.java#L346
[2] https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/GenericRuleReasoner.java#L306
-----Original Message-----
From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
Sent: vrijdag 19 januari 2018 11:38
To: users@jena.apache.org
Subject: Re: GenericRuleReasoner with limited scope
Hi Barry,
I don't understand the assembler syntax enough to directly help (no doubt others can) but given you didn't get any error messages when you had the wrong URI then not getting an error message from "bla" isn't definitive :)
As mentioned your other alternative is to leave the reasoner in hybrid mode and write your rules in backward syntax.
Dave
On 19/01/18 09:49, Nouwt, B. (Barry) wrote:
> Hi all,
>
> I fixed the error Dave found, but it does not seem to activate
> 'backward' mode. I test it by providing a wrong value 'bla' instead of
> 'backward' and check whether Fuseki fails to load the assembler. But,
> unfortunately, it doesn't fail.
>
> Any other suggestions on how to enable 'backward' mode from an
> assembler file?
>
> Regards, Barry
>
> Verzonden vanaf mijn Windows 10-telefoon
>
> *Van: *Dave Reynolds <ma...@gmail.com>
> *Verzonden: *donderdag 18 januari 2018 09:40
> *Aan: *users@jena.apache.org <ma...@jena.apache.org>
> *Onderwerp: *Re: GenericRuleReasoner with limited scope
>
> Hi Barry,
>
> I'm not sure of the assembler syntax but there's one error in your
> example which might fix it:
>
> > @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
>
> That should be:
>
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner#> .
>
> Dave
>
> On 17/01/18 15:12, Nouwt, B. (Barry) wrote:
>> Hi Dave, thanks for the answer.
>>
>> I was not aware that the backward reasoner started at triple patterns (retrieved from the SPARQL query), so I will definitely test whether that indeed causes the rule to be applied once instead of twice in the example described in my second post.
>>
>> My setup uses Apache Jena Fuseki, so the PROPruleMode should be
>> configured via a assembly TTL file. Do you know how to do that? I
>> found the 'http://jena.hpl.hp.com/2003/RuleReasoner/ruleMode'
>> property in the
> ReasonerVocabulary.java file [1], but it does not seem to load this
> property when I use the following assembly:
>>
>> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
>> .
>> .
>> .
>>
>> <#infGraph> rdf:type ja:InfModel ;
>> ja:reasoner [ ja:rulesFrom
>><file:src/test/resources/et.rules> ;
>> rr:ruleMode "backward" ; ] ;
>> ja:content <#test-inf> .
>>
>>
>> Any pointers are welcome!
>>
>> Regards, Barry
>>
>> [1]
>> https://github.com/apache/jena/blob/cc038809fb622779933831011909714e2
>> 2ef494c/jena-core/src/main/java/org/apache/jena/vocabulary/ReasonerVo
>> cabulary.java#L77
>>
>> -----Original Message-----
>> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
>> Sent: woensdag 17 januari 2018 09:33
>> To: users@jena.apache.org
>> Subject: Re: GenericRuleReasoner with limited scope
>>
>> On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
>>> Hi everyone,
>>>
>>> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>>>
>>> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>>>
>>> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
>>> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
>>
>> If I understand what you want then use the backward rather than forward engine.
>>
>> The GenericRuleReasoner contains two engines which can be used
>> separately or in a cascade (hybrid mode). For configuring this see
>> PROPruleMode in
>> https://jena.apache.org/documentation/inference/#RULEconfiguration
>>
>> The backward reasoner is driven by goals at the level of triple patterns and isn't aware of the overall sparql query so the goals are not very selective but it will at least help with point #1.
>>
>> In terms of point #2 then the backward engine, by default, will not retain any answers. You can use the tabling declarations to cause it to selectively remember the answer to specific (sub)goals if you need to see:
>> https://jena.apache.org/documentation/inference/#RULEbackward
>>
>> Note that in hybrid mode (the default) you can still use backward rules by writing them with the arrow reversed. The advantage of switching the reasoner mode is that you can use the same rule source syntax and run the rules in either forward or backward mode to test the difference.
>>
>> Dave
>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by
>> mistake, you are requested to inform the sender and delete the
>> message. TNO accepts no liability for the content of this e-mail,
>> for the manner in which you use it and for damage of any kind
> resulting from the risks inherent to the electronic transmission of
> messages.
>>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: GenericRuleReasoner with limited scope
Posted by Dave Reynolds <da...@gmail.com>.
Hi Barry,
I don't understand the assembler syntax enough to directly help (no
doubt others can) but given you didn't get any error messages when you
had the wrong URI then not getting an error message from "bla" isn't
definitive :)
As mentioned your other alternative is to leave the reasoner in hybrid
mode and write your rules in backward syntax.
Dave
On 19/01/18 09:49, Nouwt, B. (Barry) wrote:
> Hi all,
>
> I fixed the error Dave found, but it does not seem to activate
> ‘backward’ mode. I test it by providing a wrong value ‘bla’ instead of
> ‘backward’ and check whether Fuseki fails to load the assembler. But,
> unfortunately, it doesn’t fail.
>
> Any other suggestions on how to enable ‘backward’ mode from an assembler
> file?
>
> Regards, Barry
>
> Verzonden vanaf mijn Windows 10-telefoon
>
> *Van: *Dave Reynolds <ma...@gmail.com>
> *Verzonden: *donderdag 18 januari 2018 09:40
> *Aan: *users@jena.apache.org <ma...@jena.apache.org>
> *Onderwerp: *Re: GenericRuleReasoner with limited scope
>
> Hi Barry,
>
> I'm not sure of the assembler syntax but there's one error in your
> example which might fix it:
>
> > @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
>
> That should be:
>
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner#> .
>
> Dave
>
> On 17/01/18 15:12, Nouwt, B. (Barry) wrote:
>> Hi Dave, thanks for the answer.
>>
>> I was not aware that the backward reasoner started at triple patterns (retrieved from the SPARQL query), so I will definitely test whether that indeed causes the rule to be applied once instead of twice in the example described in my second post.
>>
>> My setup uses Apache Jena Fuseki, so the PROPruleMode should be configured via a assembly TTL file. Do you know how to do that? I found the 'http://jena.hpl.hp.com/2003/RuleReasoner/ruleMode' property in the
> ReasonerVocabulary.java file [1], but it does not seem to load this
> property when I use the following assembly:
>>
>> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
>> .
>> .
>> .
>>
>> <#infGraph> rdf:type ja:InfModel ;
>> ja:reasoner [ ja:rulesFrom <file:src/test/resources/et.rules> ;
>> rr:ruleMode "backward" ; ] ;
>> ja:content <#test-inf> .
>>
>>
>> Any pointers are welcome!
>>
>> Regards, Barry
>>
>> [1] https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-core/src/main/java/org/apache/jena/vocabulary/ReasonerVocabulary.java#L77
>>
>> -----Original Message-----
>> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
>> Sent: woensdag 17 januari 2018 09:33
>> To: users@jena.apache.org
>> Subject: Re: GenericRuleReasoner with limited scope
>>
>> On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
>>> Hi everyone,
>>>
>>> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>>>
>>> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>>>
>>> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
>>> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
>>
>> If I understand what you want then use the backward rather than forward engine.
>>
>> The GenericRuleReasoner contains two engines which can be used separately or in a cascade (hybrid mode). For configuring this see PROPruleMode in https://jena.apache.org/documentation/inference/#RULEconfiguration
>>
>> The backward reasoner is driven by goals at the level of triple patterns and isn't aware of the overall sparql query so the goals are not very selective but it will at least help with point #1.
>>
>> In terms of point #2 then the backward engine, by default, will not retain any answers. You can use the tabling declarations to cause it to selectively remember the answer to specific (sub)goals if you need to see:
>> https://jena.apache.org/documentation/inference/#RULEbackward
>>
>> Note that in hybrid mode (the default) you can still use backward rules by writing them with the arrow reversed. The advantage of switching the reasoner mode is that you can use the same rule source syntax and run the rules in either forward or backward mode to test the difference.
>>
>> Dave
>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind
> resulting from the risks inherent to the electronic transmission of
> messages.
>>
RE: GenericRuleReasoner with limited scope
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl>.
Hi all,
I fixed the error Dave found, but it does not seem to activate ‘backward’ mode. I test it by providing a wrong value ‘bla’ instead of ‘backward’ and check whether Fuseki fails to load the assembler. But, unfortunately, it doesn’t fail.
Any other suggestions on how to enable ‘backward’ mode from an assembler file?
Regards, Barry
Verzonden vanaf mijn Windows 10-telefoon
Van: Dave Reynolds<ma...@gmail.com>
Verzonden: donderdag 18 januari 2018 09:40
Aan: users@jena.apache.org<ma...@jena.apache.org>
Onderwerp: Re: GenericRuleReasoner with limited scope
Hi Barry,
I'm not sure of the assembler syntax but there's one error in your
example which might fix it:
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
That should be:
@prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner#> .
Dave
On 17/01/18 15:12, Nouwt, B. (Barry) wrote:
> Hi Dave, thanks for the answer.
>
> I was not aware that the backward reasoner started at triple patterns (retrieved from the SPARQL query), so I will definitely test whether that indeed causes the rule to be applied once instead of twice in the example described in my second post.
>
> My setup uses Apache Jena Fuseki, so the PROPruleMode should be configured via a assembly TTL file. Do you know how to do that? I found the 'http://jena.hpl.hp.com/2003/RuleReasoner/ruleMode' property in the ReasonerVocabulary.java file [1], but it does not seem to load this property when I use the following assembly:
>
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
> .
> .
> .
>
> <#infGraph> rdf:type ja:InfModel ;
> ja:reasoner [ ja:rulesFrom <file:src/test/resources/et.rules> ;
> rr:ruleMode "backward" ; ] ;
> ja:content <#test-inf> .
>
>
> Any pointers are welcome!
>
> Regards, Barry
>
> [1] https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-core/src/main/java/org/apache/jena/vocabulary/ReasonerVocabulary.java#L77
>
> -----Original Message-----
> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
> Sent: woensdag 17 januari 2018 09:33
> To: users@jena.apache.org
> Subject: Re: GenericRuleReasoner with limited scope
>
> On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
>> Hi everyone,
>>
>> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>>
>> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>>
>> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
>> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
>
> If I understand what you want then use the backward rather than forward engine.
>
> The GenericRuleReasoner contains two engines which can be used separately or in a cascade (hybrid mode). For configuring this see PROPruleMode in https://jena.apache.org/documentation/inference/#RULEconfiguration
>
> The backward reasoner is driven by goals at the level of triple patterns and isn't aware of the overall sparql query so the goals are not very selective but it will at least help with point #1.
>
> In terms of point #2 then the backward engine, by default, will not retain any answers. You can use the tabling declarations to cause it to selectively remember the answer to specific (sub)goals if you need to see:
> https://jena.apache.org/documentation/inference/#RULEbackward
>
> Note that in hybrid mode (the default) you can still use backward rules by writing them with the arrow reversed. The advantage of switching the reasoner mode is that you can use the same rule source syntax and run the rules in either forward or backward mode to test the difference.
>
> Dave
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
Re: GenericRuleReasoner with limited scope
Posted by Dave Reynolds <da...@gmail.com>.
Hi Barry,
I'm not sure of the assembler syntax but there's one error in your
example which might fix it:
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
That should be:
@prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner#> .
Dave
On 17/01/18 15:12, Nouwt, B. (Barry) wrote:
> Hi Dave, thanks for the answer.
>
> I was not aware that the backward reasoner started at triple patterns (retrieved from the SPARQL query), so I will definitely test whether that indeed causes the rule to be applied once instead of twice in the example described in my second post.
>
> My setup uses Apache Jena Fuseki, so the PROPruleMode should be configured via a assembly TTL file. Do you know how to do that? I found the 'http://jena.hpl.hp.com/2003/RuleReasoner/ruleMode' property in the ReasonerVocabulary.java file [1], but it does not seem to load this property when I use the following assembly:
>
> @prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
> .
> .
> .
>
> <#infGraph> rdf:type ja:InfModel ;
> ja:reasoner [ ja:rulesFrom <file:src/test/resources/et.rules> ;
> rr:ruleMode "backward" ; ] ;
> ja:content <#test-inf> .
>
>
> Any pointers are welcome!
>
> Regards, Barry
>
> [1] https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-core/src/main/java/org/apache/jena/vocabulary/ReasonerVocabulary.java#L77
>
> -----Original Message-----
> From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
> Sent: woensdag 17 januari 2018 09:33
> To: users@jena.apache.org
> Subject: Re: GenericRuleReasoner with limited scope
>
> On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
>> Hi everyone,
>>
>> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>>
>> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>>
>> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
>> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
>
> If I understand what you want then use the backward rather than forward engine.
>
> The GenericRuleReasoner contains two engines which can be used separately or in a cascade (hybrid mode). For configuring this see PROPruleMode in https://jena.apache.org/documentation/inference/#RULEconfiguration
>
> The backward reasoner is driven by goals at the level of triple patterns and isn't aware of the overall sparql query so the goals are not very selective but it will at least help with point #1.
>
> In terms of point #2 then the backward engine, by default, will not retain any answers. You can use the tabling declarations to cause it to selectively remember the answer to specific (sub)goals if you need to see:
> https://jena.apache.org/documentation/inference/#RULEbackward
>
> Note that in hybrid mode (the default) you can still use backward rules by writing them with the arrow reversed. The advantage of switching the reasoner mode is that you can use the same rule source syntax and run the rules in either forward or backward mode to test the difference.
>
> Dave
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
RE: GenericRuleReasoner with limited scope
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl>.
Hi Dave, thanks for the answer.
I was not aware that the backward reasoner started at triple patterns (retrieved from the SPARQL query), so I will definitely test whether that indeed causes the rule to be applied once instead of twice in the example described in my second post.
My setup uses Apache Jena Fuseki, so the PROPruleMode should be configured via a assembly TTL file. Do you know how to do that? I found the 'http://jena.hpl.hp.com/2003/RuleReasoner/ruleMode' property in the ReasonerVocabulary.java file [1], but it does not seem to load this property when I use the following assembly:
@prefix rr: <http://jena.hpl.hp.com/2003/RuleReasoner> .
.
.
.
<#infGraph> rdf:type ja:InfModel ;
ja:reasoner [ ja:rulesFrom <file:src/test/resources/et.rules> ;
rr:ruleMode "backward" ; ] ;
ja:content <#test-inf> .
Any pointers are welcome!
Regards, Barry
[1] https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-core/src/main/java/org/apache/jena/vocabulary/ReasonerVocabulary.java#L77
-----Original Message-----
From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com]
Sent: woensdag 17 januari 2018 09:33
To: users@jena.apache.org
Subject: Re: GenericRuleReasoner with limited scope
On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
> Hi everyone,
>
> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>
> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>
> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
If I understand what you want then use the backward rather than forward engine.
The GenericRuleReasoner contains two engines which can be used separately or in a cascade (hybrid mode). For configuring this see PROPruleMode in https://jena.apache.org/documentation/inference/#RULEconfiguration
The backward reasoner is driven by goals at the level of triple patterns and isn't aware of the overall sparql query so the goals are not very selective but it will at least help with point #1.
In terms of point #2 then the backward engine, by default, will not retain any answers. You can use the tabling declarations to cause it to selectively remember the answer to specific (sub)goals if you need to see:
https://jena.apache.org/documentation/inference/#RULEbackward
Note that in hybrid mode (the default) you can still use backward rules by writing them with the arrow reversed. The advantage of switching the reasoner mode is that you can use the same rule source syntax and run the rules in either forward or backward mode to test the difference.
Dave
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: GenericRuleReasoner with limited scope
Posted by Dave Reynolds <da...@gmail.com>.
On 16/01/18 09:55, Nouwt, B. (Barry) wrote:
> Hi everyone,
>
> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>
> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>
> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
If I understand what you want then use the backward rather than forward
engine.
The GenericRuleReasoner contains two engines which can be used
separately or in a cascade (hybrid mode). For configuring this see
PROPruleMode in
https://jena.apache.org/documentation/inference/#RULEconfiguration
The backward reasoner is driven by goals at the level of triple patterns
and isn't aware of the overall sparql query so the goals are not very
selective but it will at least help with point #1.
In terms of point #2 then the backward engine, by default, will not
retain any answers. You can use the tabling declarations to cause it to
selectively remember the answer to specific (sub)goals if you need to see:
https://jena.apache.org/documentation/inference/#RULEbackward
Note that in hybrid mode (the default) you can still use backward rules
by writing them with the arrow reversed. The advantage of switching the
reasoner mode is that you can use the same rule source syntax and run
the rules in either forward or backward mode to test the difference.
Dave
RE: GenericRuleReasoner with limited scope
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl>.
Hi everyone, thanks for your answers.
@Lorenz Buehmann: I am currently only using SELECT SPARQL queries and no CONSTRUCT SPARQL queries. Also, I think the strategy for first executing the SPARQL query and use the output as input to the reasoner is not going to work if the SELECT SPARQL query selects inferred triples. However, the strategy where the SPARQL query is reduced in steps until it gives results and use these results as the starting point for a reasoner might be a valid strategy.
@ Martynas Jusevičius: I'm not directly interested in extending Apache Jena's rule engine to include SPARQL queries in the rules, but it is interesting from the perspective on how to extend Jena's rule engine.
Maybe an example helps explaining my use case. If I have the following (not that useful) data.ttl file:
@prefix tno: <http://tno.nl/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
tno:A rdf:type tno:Country .
tno:A tno:hasProduction tno:B .
tno:B rdf:type tno:Production .
tno:B tno:productionOfCountry tno:A .
tno:C rdf:type tno:Country .
tno:C tno:hasProduction tno:D .
tno:D rdf:type tno:Production .
tno:D tno:productionOfCountry tno:C .
And a file et.rules with the following rule:
@prefix tno: <http://tno.nl/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
[test: (?a rdf:type tno:Country) (?a tno:hasProduction ?b) -> (?a rdf:type tno:ProducingCountry) ]
And I execute the following SPARQL Query:
SELECT ?object
WHERE {
tno:A a tno:ProducingCountry .
tno:A tno:hasProduction ?object .
}
The GenericRuleReasoner first applies the rule above twice and derives two new triples:
tno:A a tno:ProducingCountry
tno:C a tno:ProducingCountry
And then executes the SPARQL Query above on the data.ttl data together with the two new triples above and gives the following result:
tno:B
Now what I would like the GenericRuleReasoner to do, is the following. After I execute the SPARQL Query above, the reasoner would 'see' that the SPARQL query is only interested in the subject tno:A and not in subject tno:C. So, instead of applying the rule twice to both tno:A and tno:C, it would only apply it to tno:A. Then there would only be a single inferred triple:
tno:A a tno:ProducingCountry
And the query result would again be:
tno:B
I hope this helps with understanding what I meant with my point 1 in my initial email. Any pointers on how to achieve this?
Regards, Barry
-----Original Message-----
From: Lorenz Buehmann [mailto:buehmann@informatik.uni-leipzig.de]
Sent: dinsdag 16 januari 2018 13:29
To: users@jena.apache.org
Subject: Re: GenericRuleReasoner with limited scope
Source code [1]
Jena version: 2.12.1-SNAPSHOT
[1] https://github.com/mbentoalves/jena/tree/trunk/jena-core
On 16.01.2018 12:56, Martynas Jusevičius wrote:
> There is also something like this:
> https://www.researchgate.net/publication/307934931_SPARQL_Commands_in_
> Jena_Rules
>
> On Tue, Jan 16, 2018 at 12:21 PM, Lorenz Buehmann <
> buehmann@informatik.uni-leipzig.de> wrote:
>
>>> I would like the GenericRuleReasoner to take the SPARQL query into
>> account when reasoning. So, only reason about those facts that 'seem'
>> relevant for answering the SPARQL query.
>> Wouldn't the logical way here to execute the SPARQL query (it has to
>> be a CONSTRUCT query indeed) and use the model returned here as the
>> input of the reasoner?
>>
>>
>> On 16.01.2018 10:55, Nouwt, B. (Barry) wrote:
>>> Hi everyone,
>>>
>>> Currently I'm using the GenericRuleReasoner of Apache Jena in my
>>> project
>> to apply custom rules to my RDF data. This works as expected: as soon
>> as I execute the first SPARQL query in Apache Jena Fuseki, the
>> GenericRuleReasoner correctly determines all the derived triples and
>> the query can be answered.
>>> Now I am looking for the following GenericRuleReasoner (or another
>> reasoner) behavior:
>>> 1. I would like the GenericRuleReasoner to take the SPARQL query
>>> into
>> account when reasoning. So, only reason about those facts that 'seem'
>> relevant for answering the SPARQL query.
>>> 2. I would like the GenericRuleReasoner to remove the derived
>>> triples
>> after the SPARQL query has been answered. So, the next time it
>> receives the same SPARQL query, it will not be able to reuse the
>> previous reasoning result.
>>> Note:
>>>
>>> * I am willing to accept some incomplete answers to get the
>> functionality described in 1.
>>> * In literature I found the term 'query answering' as one of the
>> things a reasoner can do, which looks like the behavior I describe in
>> point
>> 1 above. It is also mentioned here: http://ontogenesis.
>> knowledgeblog.org/1486
>>> Does anyone know whether the behavior described above is possible
>>> (does
>> Apache Jena allow the reasoner to use the SPARQL query as input at
>> all) and whether there are rule engine implementations for Jena
>> available that implement such behavior? Is it possible to configure
>> Jena in such a way that it restarts the reasoner for every query it receives?
>>> Any other pointers that help me understand this reasoner related
>>> subject
>> are welcome as well.
>>> Regards,
>>>
>>> Barry
>>> This message may contain information that is not intended for you.
>>> If
>> you are not the addressee or if this message was sent to you by
>> mistake, you are requested to inform the sender and delete the
>> message. TNO accepts no liability for the content of this e-mail, for
>> the manner in which you use it and for damage of any kind resulting
>> from the risks inherent to the electronic transmission of messages.
>>
Re: GenericRuleReasoner with limited scope
Posted by Lorenz Buehmann <bu...@informatik.uni-leipzig.de>.
Source code [1]
Jena version: 2.12.1-SNAPSHOT
[1] https://github.com/mbentoalves/jena/tree/trunk/jena-core
On 16.01.2018 12:56, Martynas Jusevičius wrote:
> There is also something like this:
> https://www.researchgate.net/publication/307934931_SPARQL_Commands_in_Jena_Rules
>
> On Tue, Jan 16, 2018 at 12:21 PM, Lorenz Buehmann <
> buehmann@informatik.uni-leipzig.de> wrote:
>
>>> I would like the GenericRuleReasoner to take the SPARQL query into
>> account when reasoning. So, only reason about those facts that 'seem'
>> relevant for answering the SPARQL query.
>> Wouldn't the logical way here to execute the SPARQL query (it has to be
>> a CONSTRUCT query indeed) and use the model returned here as the input
>> of the reasoner?
>>
>>
>> On 16.01.2018 10:55, Nouwt, B. (Barry) wrote:
>>> Hi everyone,
>>>
>>> Currently I'm using the GenericRuleReasoner of Apache Jena in my project
>> to apply custom rules to my RDF data. This works as expected: as soon as I
>> execute the first SPARQL query in Apache Jena Fuseki, the
>> GenericRuleReasoner correctly determines all the derived triples and the
>> query can be answered.
>>> Now I am looking for the following GenericRuleReasoner (or another
>> reasoner) behavior:
>>> 1. I would like the GenericRuleReasoner to take the SPARQL query into
>> account when reasoning. So, only reason about those facts that 'seem'
>> relevant for answering the SPARQL query.
>>> 2. I would like the GenericRuleReasoner to remove the derived triples
>> after the SPARQL query has been answered. So, the next time it receives the
>> same SPARQL query, it will not be able to reuse the previous reasoning
>> result.
>>> Note:
>>>
>>> * I am willing to accept some incomplete answers to get the
>> functionality described in 1.
>>> * In literature I found the term 'query answering' as one of the
>> things a reasoner can do, which looks like the behavior I describe in point
>> 1 above. It is also mentioned here: http://ontogenesis.
>> knowledgeblog.org/1486
>>> Does anyone know whether the behavior described above is possible (does
>> Apache Jena allow the reasoner to use the SPARQL query as input at all) and
>> whether there are rule engine implementations for Jena available that
>> implement such behavior? Is it possible to configure Jena in such a way
>> that it restarts the reasoner for every query it receives?
>>> Any other pointers that help me understand this reasoner related subject
>> are welcome as well.
>>> Regards,
>>>
>>> Barry
>>> This message may contain information that is not intended for you. If
>> you are not the addressee or if this message was sent to you by mistake,
>> you are requested to inform the sender and delete the message. TNO accepts
>> no liability for the content of this e-mail, for the manner in which you
>> use it and for damage of any kind resulting from the risks inherent to the
>> electronic transmission of messages.
>>
Re: GenericRuleReasoner with limited scope
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
There is also something like this:
https://www.researchgate.net/publication/307934931_SPARQL_Commands_in_Jena_Rules
On Tue, Jan 16, 2018 at 12:21 PM, Lorenz Buehmann <
buehmann@informatik.uni-leipzig.de> wrote:
> > I would like the GenericRuleReasoner to take the SPARQL query into
> account when reasoning. So, only reason about those facts that 'seem'
> relevant for answering the SPARQL query.
> Wouldn't the logical way here to execute the SPARQL query (it has to be
> a CONSTRUCT query indeed) and use the model returned here as the input
> of the reasoner?
>
>
> On 16.01.2018 10:55, Nouwt, B. (Barry) wrote:
> > Hi everyone,
> >
> > Currently I'm using the GenericRuleReasoner of Apache Jena in my project
> to apply custom rules to my RDF data. This works as expected: as soon as I
> execute the first SPARQL query in Apache Jena Fuseki, the
> GenericRuleReasoner correctly determines all the derived triples and the
> query can be answered.
> >
> > Now I am looking for the following GenericRuleReasoner (or another
> reasoner) behavior:
> >
> > 1. I would like the GenericRuleReasoner to take the SPARQL query into
> account when reasoning. So, only reason about those facts that 'seem'
> relevant for answering the SPARQL query.
> > 2. I would like the GenericRuleReasoner to remove the derived triples
> after the SPARQL query has been answered. So, the next time it receives the
> same SPARQL query, it will not be able to reuse the previous reasoning
> result.
> >
> > Note:
> >
> > * I am willing to accept some incomplete answers to get the
> functionality described in 1.
> > * In literature I found the term 'query answering' as one of the
> things a reasoner can do, which looks like the behavior I describe in point
> 1 above. It is also mentioned here: http://ontogenesis.
> knowledgeblog.org/1486
> >
> > Does anyone know whether the behavior described above is possible (does
> Apache Jena allow the reasoner to use the SPARQL query as input at all) and
> whether there are rule engine implementations for Jena available that
> implement such behavior? Is it possible to configure Jena in such a way
> that it restarts the reasoner for every query it receives?
> >
> > Any other pointers that help me understand this reasoner related subject
> are welcome as well.
> >
> > Regards,
> >
> > Barry
> > This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by mistake,
> you are requested to inform the sender and delete the message. TNO accepts
> no liability for the content of this e-mail, for the manner in which you
> use it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
> >
>
>
Re: GenericRuleReasoner with limited scope
Posted by Lorenz Buehmann <bu...@informatik.uni-leipzig.de>.
> I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
Wouldn't the logical way here to execute the SPARQL query (it has to be
a CONSTRUCT query indeed) and use the model returned here as the input
of the reasoner?
On 16.01.2018 10:55, Nouwt, B. (Barry) wrote:
> Hi everyone,
>
> Currently I'm using the GenericRuleReasoner of Apache Jena in my project to apply custom rules to my RDF data. This works as expected: as soon as I execute the first SPARQL query in Apache Jena Fuseki, the GenericRuleReasoner correctly determines all the derived triples and the query can be answered.
>
> Now I am looking for the following GenericRuleReasoner (or another reasoner) behavior:
>
> 1. I would like the GenericRuleReasoner to take the SPARQL query into account when reasoning. So, only reason about those facts that 'seem' relevant for answering the SPARQL query.
> 2. I would like the GenericRuleReasoner to remove the derived triples after the SPARQL query has been answered. So, the next time it receives the same SPARQL query, it will not be able to reuse the previous reasoning result.
>
> Note:
>
> * I am willing to accept some incomplete answers to get the functionality described in 1.
> * In literature I found the term 'query answering' as one of the things a reasoner can do, which looks like the behavior I describe in point 1 above. It is also mentioned here: http://ontogenesis.knowledgeblog.org/1486
>
> Does anyone know whether the behavior described above is possible (does Apache Jena allow the reasoner to use the SPARQL query as input at all) and whether there are rule engine implementations for Jena available that implement such behavior? Is it possible to configure Jena in such a way that it restarts the reasoner for every query it receives?
>
> Any other pointers that help me understand this reasoner related subject are welcome as well.
>
> Regards,
>
> Barry
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>