You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Igor Brussilowski <ig...@yahoo.de> on 2013/08/05 15:02:51 UTC
Access list values in rules
Hi all,
I'm looking for how to access list items in a reasoner rule. E.g the pattern (?S owl:kasKey ?L) returns a list of all matching objects. Is there any way to access here the elements of the list for further processing, e.g. to print them all out?
Thanks
Igor
Re: Access list values in rules
Posted by Igor Brussilowski <ig...@yahoo.de>.
ok, its now more clear for me. I'll try to setup my reasoner with the pre-compilation of the list rules.
Thank you Dave.
Igor
----- Ursprüngliche Message -----
> Von: Dave Reynolds <da...@gmail.com>
> An: users@jena.apache.org
> CC:
> Gesendet: 9:44 Dienstag, 6.August 2013
> Betreff: Re: Access list values in rules
>
> On 06/08/13 08:18, Igor Brussilowski wrote:
>>
>>
>> ----- Ursprüngliche Message -----
>>> Von: Dave Reynolds <da...@gmail.com>
>>> An: users@jena.apache.org
>>> CC:
>>> Gesendet: 0:15 Dienstag, 6.August 2013
>>> Betreff: Re: Access list values in rules
>>>
>>> On 05/08/13 21:41, Igor Brussilowski wrote:
>>>> Hi, thank you for reply.
>>>>
>>>> I sure know all these builtin functions but I'm not sure that
> they pass
>>> to my case. May be I have to describe the scenario in more details.
>>>>
>>>> Here pseudo code:
>>>>
>>>>
>>>> given (?s hasList ?list)
>>>> if for all ?p in ?list
>>>>
>>>> (?s1 ?p ?o1) (?s2 ?p ?o2) equal(?o1 ?o2)
>>>> then
>>>>
>>>> -> do smth
>>>
>>> No that's not directly possible in Jena rules since it involves
> implicit
>>> negation (for all in the head). Jena is designed for monotonic
> deductive
>>> closure. Jena does have the various non-monotonic hacks like noValue
> but
>>> there is no real negation supported.
>>>
>>> However *if* your hasList values are fixed throughout the rule
>>> processing then you could achieve this through rule compilation.
>>> Pre-process your rule set to translate such a rule into:
>>>
>>> (?sa1 ?pa ?oa1) (?sa2 ?pa ?oa2) equal(?oa1 ?oa2)
>>> (?sb1 ?pb ?ob1) (?sb2 ?pb ?ob2) equal(?ob1 ?ob2)
>>> ...
>>> -> do smth
>>>
>>> Where pa, pb etc are the fixed set of entries in your list.
>>>
>>> However, the equals in that case is pointless so this would be much
>>> better as:
>>>
>>> (?sa1 ?pa ?oa) (?sa2 ?pa ?oa)
>>> (?sb1 ?pb ?ob) (?sb2 ?pb ?ob)
>>> ...
>>> -> do smth
>>
>>
>> Right, indeed I do exact so in the builtin solution, the *equal* here was
> only to explain the evaluation logic.
>>
>> The hasList property (the owl:hasKey actually) delivers different lists for
> different classes in ontology, but these lists are then constant. I did not find
> how to iterate such lists in the rule definition, therefore I wrote the
> mentioned builtin to evaluate the lists at runtime in the java code, but as I
> said I'm afraid that this runtime rule processing is less performant,
> because it calls the Graph.find to evaluate the assertion (?s1 ?p ?o) (?s2 ?p
> ?o) for all ?p in the given ?list. Or is this really a legal way to do this?
>
> There's no problem with the performance, that will actually be faster
> because it is side stepping all the rule machinery, the problem is
> completeness. As I say, if a new (?s1 ?p ?o1) is added by some other
> rules then your rule will not fire.
>
>> Another solution which I probed is to pre-compile the rules (as you also
> suggest) for different lists from ontology at startup. But I had difficult to
> setup this solution in the joseki's config file for reasoner initialization.
> Do you think this *pre-compile* solution would be better than the *runtime* one
> mentioned above?
>
> Unless for some reason you are sure that your fire-once builtin is
> sufficient for your particular purposes then yes the compilation
> approach would be better. You can package that up as a reasoner. In fact
> the built in OWL reasoners do something similar for the intersectionOf
> cases.
>
> In principle it should be possible to wire up a new reasoner within
> Joseki (are you really still on Joseki?) using assemblers but I don't
> understand assemblers well enough to advise on how to do that.
>
> Dave
>
Re: Access list values in rules
Posted by Dave Reynolds <da...@gmail.com>.
On 06/08/13 08:18, Igor Brussilowski wrote:
>
>
> ----- Ursprüngliche Message -----
>> Von: Dave Reynolds <da...@gmail.com>
>> An: users@jena.apache.org
>> CC:
>> Gesendet: 0:15 Dienstag, 6.August 2013
>> Betreff: Re: Access list values in rules
>>
>> On 05/08/13 21:41, Igor Brussilowski wrote:
>>> Hi, thank you for reply.
>>>
>>> I sure know all these builtin functions but I'm not sure that they pass
>> to my case. May be I have to describe the scenario in more details.
>>>
>>> Here pseudo code:
>>>
>>>
>>> given (?s hasList ?list)
>>> if for all ?p in ?list
>>>
>>> (?s1 ?p ?o1) (?s2 ?p ?o2) equal(?o1 ?o2)
>>> then
>>>
>>> -> do smth
>>
>> No that's not directly possible in Jena rules since it involves implicit
>> negation (for all in the head). Jena is designed for monotonic deductive
>> closure. Jena does have the various non-monotonic hacks like noValue but
>> there is no real negation supported.
>>
>> However *if* your hasList values are fixed throughout the rule
>> processing then you could achieve this through rule compilation.
>> Pre-process your rule set to translate such a rule into:
>>
>> (?sa1 ?pa ?oa1) (?sa2 ?pa ?oa2) equal(?oa1 ?oa2)
>> (?sb1 ?pb ?ob1) (?sb2 ?pb ?ob2) equal(?ob1 ?ob2)
>> ...
>> -> do smth
>>
>> Where pa, pb etc are the fixed set of entries in your list.
>>
>> However, the equals in that case is pointless so this would be much
>> better as:
>>
>> (?sa1 ?pa ?oa) (?sa2 ?pa ?oa)
>> (?sb1 ?pb ?ob) (?sb2 ?pb ?ob)
>> ...
>> -> do smth
>
>
> Right, indeed I do exact so in the builtin solution, the *equal* here was only to explain the evaluation logic.
>
> The hasList property (the owl:hasKey actually) delivers different lists for different classes in ontology, but these lists are then constant. I did not find how to iterate such lists in the rule definition, therefore I wrote the mentioned builtin to evaluate the lists at runtime in the java code, but as I said I'm afraid that this runtime rule processing is less performant, because it calls the Graph.find to evaluate the assertion (?s1 ?p ?o) (?s2 ?p ?o) for all ?p in the given ?list. Or is this really a legal way to do this?
There's no problem with the performance, that will actually be faster
because it is side stepping all the rule machinery, the problem is
completeness. As I say, if a new (?s1 ?p ?o1) is added by some other
rules then your rule will not fire.
> Another solution which I probed is to pre-compile the rules (as you also suggest) for different lists from ontology at startup. But I had difficult to setup this solution in the joseki's config file for reasoner initialization. Do you think this *pre-compile* solution would be better than the *runtime* one mentioned above?
Unless for some reason you are sure that your fire-once builtin is
sufficient for your particular purposes then yes the compilation
approach would be better. You can package that up as a reasoner. In fact
the built in OWL reasoners do something similar for the intersectionOf
cases.
In principle it should be possible to wire up a new reasoner within
Joseki (are you really still on Joseki?) using assemblers but I don't
understand assemblers well enough to advise on how to do that.
Dave
Re: Access list values in rules
Posted by Igor Brussilowski <ig...@yahoo.de>.
----- Ursprüngliche Message -----
> Von: Dave Reynolds <da...@gmail.com>
> An: users@jena.apache.org
> CC:
> Gesendet: 0:15 Dienstag, 6.August 2013
> Betreff: Re: Access list values in rules
>
> On 05/08/13 21:41, Igor Brussilowski wrote:
>> Hi, thank you for reply.
>>
>> I sure know all these builtin functions but I'm not sure that they pass
> to my case. May be I have to describe the scenario in more details.
>>
>> Here pseudo code:
>>
>>
>> given (?s hasList ?list)
>> if for all ?p in ?list
>>
>> (?s1 ?p ?o1) (?s2 ?p ?o2) equal(?o1 ?o2)
>> then
>>
>> -> do smth
>
> No that's not directly possible in Jena rules since it involves implicit
> negation (for all in the head). Jena is designed for monotonic deductive
> closure. Jena does have the various non-monotonic hacks like noValue but
> there is no real negation supported.
>
> However *if* your hasList values are fixed throughout the rule
> processing then you could achieve this through rule compilation.
> Pre-process your rule set to translate such a rule into:
>
> (?sa1 ?pa ?oa1) (?sa2 ?pa ?oa2) equal(?oa1 ?oa2)
> (?sb1 ?pb ?ob1) (?sb2 ?pb ?ob2) equal(?ob1 ?ob2)
> ...
> -> do smth
>
> Where pa, pb etc are the fixed set of entries in your list.
>
> However, the equals in that case is pointless so this would be much
> better as:
>
> (?sa1 ?pa ?oa) (?sa2 ?pa ?oa)
> (?sb1 ?pb ?ob) (?sb2 ?pb ?ob)
> ...
> -> do smth
Right, indeed I do exact so in the builtin solution, the *equal* here was only to explain the evaluation logic.
The hasList property (the owl:hasKey actually) delivers different lists for different classes in ontology, but these lists are then constant. I did not find how to iterate such lists in the rule definition, therefore I wrote the mentioned builtin to evaluate the lists at runtime in the java code, but as I said I'm afraid that this runtime rule processing is less performant, because it calls the Graph.find to evaluate the assertion (?s1 ?p ?o) (?s2 ?p ?o) for all ?p in the given ?list. Or is this really a legal way to do this?
Another solution which I probed is to pre-compile the rules (as you also suggest) for different lists from ontology at startup. But I had difficult to setup this solution in the joseki's config file for reasoner initialization. Do you think this *pre-compile* solution would be better than the *runtime* one mentioned above?
>
> Since you have equals in there maybe you actually mean something
> stronger than your pseudo code suggests.
>
>> I have already written a bultin function for this functionality (pseudo):
>>
>> (?s hasList ?list)
>> -> myBuiltin(?s1 ?s2 ?list)
>>
>>
>> but I have to do graph find within the builtin's headAction to get the
> results of (?s1 ?p ?o1) (?s2 ?p ?o2) and I'm afraid that this decrease the
> performance of the rule processing (or is it ok to do this?), therefore I'm
> looking for rule optimization.
>
> The problem with that is the non-monotonicity. If some ?p value changes
> then you would get a different result from your builtin but your rule
> will not refire.
>
> Dave
>
>>
>> Regards,
>> Igor
>>
>>
>>
>>
>> ----- Ursprüngliche Message -----
>>> Von: Joshua TAYLOR <jo...@gmail.com>
>>> An: users@jena.apache.org; Igor Brussilowski
> <ig...@yahoo.de>
>>> CC:
>>> Gesendet: 20:50 Montag, 5.August 2013
>>> Betreff: Re: Access list values in rules
>>>
>>> On Mon, Aug 5, 2013 at 9:02 AM, Igor Brussilowski
>>> <ig...@yahoo.de> wrote:
>>>> Hi all,
>>>>
>>>> I'm looking for how to access list items in a reasoner rule.
> E.g the
>>> pattern (?S owl:kasKey ?L) returns a list of all matching objects. Is
> there any
>>> way to access here the elements of the list for further processing,
> e.g. to
>>> print them all out?
>>>
>>> According to the documentation [1], there are a number of builtins for
>>> working with lists:
>>>
>>> listContains(?l, ?x)
>>> listNotContains(?l, ?x)
>>> Passes if ?l is a list which contains (does not contain) the element
>>> ?x, both arguments must be ground, can not be used as a generator.
>>>
>>> listEntry(?list, ?index, ?val)
>>> Binds ?val to the ?index'th entry in the RDF list ?list. If there
> is
>>> no such entry the variable will be unbound and the call will fail.
>>> Only useable in rule bodies.
>>>
>>> listLength(?l, ?len)
>>> Binds ?len to the length of the list ?l.
>>>
>>> listEqual(?la, ?lb)
>>> listNotEqual(?la, ?lb)
>>> listEqual tests if the two arguments are both lists and contain the
>>> same elements. The equality test is semantic equality on literals
>>> (sameValueAs) but will not take into account owl:sameAs aliases.
>>> listNotEqual is the negation of this (passes if listEqual fails).
>>>
>>> listMapAsObject(?s, ?p ?l)
>>> listMapAsSubject(?l, ?p, ?o)
>>> These can only be used as actions in the head of a rule. They deduce a
>>> set of triples derived from the list argument ?l : listMapAsObject
>>> asserts triples (?s ?p ?x) for each ?x in the list ?l,
>>> listMapAsSubject asserts triples (?x ?p ?o).
>>>
>>> [1] http://jena.apache.org/documentation/inference/#RULEbuiltins
>>>
>>> --
>>> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
>>>
>
Re: Access list values in rules
Posted by Dave Reynolds <da...@gmail.com>.
On 05/08/13 21:41, Igor Brussilowski wrote:
> Hi, thank you for reply.
>
> I sure know all these builtin functions but I'm not sure that they pass to my case. May be I have to describe the scenario in more details.
>
> Here pseudo code:
>
>
> given (?s hasList ?list)
> if for all ?p in ?list
>
> (?s1 ?p ?o1) (?s2 ?p ?o2) equal(?o1 ?o2)
> then
>
> -> do smth
No that's not directly possible in Jena rules since it involves implicit
negation (for all in the head). Jena is designed for monotonic deductive
closure. Jena does have the various non-monotonic hacks like noValue but
there is no real negation supported.
However *if* your hasList values are fixed throughout the rule
processing then you could achieve this through rule compilation.
Pre-process your rule set to translate such a rule into:
(?sa1 ?pa ?oa1) (?sa2 ?pa ?oa2) equal(?oa1 ?oa2)
(?sb1 ?pb ?ob1) (?sb2 ?pb ?ob2) equal(?ob1 ?ob2)
...
-> do smth
Where pa, pb etc are the fixed set of entries in your list.
However, the equals in that case is pointless so this would be much
better as:
(?sa1 ?pa ?oa) (?sa2 ?pa ?oa)
(?sb1 ?pb ?ob) (?sb2 ?pb ?ob)
...
-> do smth
Since you have equals in there maybe you actually mean something
stronger than your pseudo code suggests.
> I have already written a bultin function for this functionality (pseudo):
>
> (?s hasList ?list)
> -> myBuiltin(?s1 ?s2 ?list)
>
>
> but I have to do graph find within the builtin's headAction to get the results of (?s1 ?p ?o1) (?s2 ?p ?o2) and I'm afraid that this decrease the performance of the rule processing (or is it ok to do this?), therefore I'm looking for rule optimization.
The problem with that is the non-monotonicity. If some ?p value changes
then you would get a different result from your builtin but your rule
will not refire.
Dave
>
> Regards,
> Igor
>
>
>
>
> ----- Ursprüngliche Message -----
>> Von: Joshua TAYLOR <jo...@gmail.com>
>> An: users@jena.apache.org; Igor Brussilowski <ig...@yahoo.de>
>> CC:
>> Gesendet: 20:50 Montag, 5.August 2013
>> Betreff: Re: Access list values in rules
>>
>> On Mon, Aug 5, 2013 at 9:02 AM, Igor Brussilowski
>> <ig...@yahoo.de> wrote:
>>> Hi all,
>>>
>>> I'm looking for how to access list items in a reasoner rule. E.g the
>> pattern (?S owl:kasKey ?L) returns a list of all matching objects. Is there any
>> way to access here the elements of the list for further processing, e.g. to
>> print them all out?
>>
>> According to the documentation [1], there are a number of builtins for
>> working with lists:
>>
>> listContains(?l, ?x)
>> listNotContains(?l, ?x)
>> Passes if ?l is a list which contains (does not contain) the element
>> ?x, both arguments must be ground, can not be used as a generator.
>>
>> listEntry(?list, ?index, ?val)
>> Binds ?val to the ?index'th entry in the RDF list ?list. If there is
>> no such entry the variable will be unbound and the call will fail.
>> Only useable in rule bodies.
>>
>> listLength(?l, ?len)
>> Binds ?len to the length of the list ?l.
>>
>> listEqual(?la, ?lb)
>> listNotEqual(?la, ?lb)
>> listEqual tests if the two arguments are both lists and contain the
>> same elements. The equality test is semantic equality on literals
>> (sameValueAs) but will not take into account owl:sameAs aliases.
>> listNotEqual is the negation of this (passes if listEqual fails).
>>
>> listMapAsObject(?s, ?p ?l)
>> listMapAsSubject(?l, ?p, ?o)
>> These can only be used as actions in the head of a rule. They deduce a
>> set of triples derived from the list argument ?l : listMapAsObject
>> asserts triples (?s ?p ?x) for each ?x in the list ?l,
>> listMapAsSubject asserts triples (?x ?p ?o).
>>
>> [1] http://jena.apache.org/documentation/inference/#RULEbuiltins
>>
>> --
>> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
>>
Re: Access list values in rules
Posted by Igor Brussilowski <ig...@yahoo.de>.
Hi, thank you for reply.
I sure know all these builtin functions but I'm not sure that they pass to my case. May be I have to describe the scenario in more details.
Here pseudo code:
given (?s hasList ?list)
if for all ?p in ?list
(?s1 ?p ?o1) (?s2 ?p ?o2) equal(?o1 ?o2)
then
-> do smth
I have already written a bultin function for this functionality (pseudo):
(?s hasList ?list)
-> myBuiltin(?s1 ?s2 ?list)
but I have to do graph find within the builtin's headAction to get the results of (?s1 ?p ?o1) (?s2 ?p ?o2) and I'm afraid that this decrease the performance of the rule processing (or is it ok to do this?), therefore I'm looking for rule optimization.
Regards,
Igor
----- Ursprüngliche Message -----
> Von: Joshua TAYLOR <jo...@gmail.com>
> An: users@jena.apache.org; Igor Brussilowski <ig...@yahoo.de>
> CC:
> Gesendet: 20:50 Montag, 5.August 2013
> Betreff: Re: Access list values in rules
>
> On Mon, Aug 5, 2013 at 9:02 AM, Igor Brussilowski
> <ig...@yahoo.de> wrote:
>> Hi all,
>>
>> I'm looking for how to access list items in a reasoner rule. E.g the
> pattern (?S owl:kasKey ?L) returns a list of all matching objects. Is there any
> way to access here the elements of the list for further processing, e.g. to
> print them all out?
>
> According to the documentation [1], there are a number of builtins for
> working with lists:
>
> listContains(?l, ?x)
> listNotContains(?l, ?x)
> Passes if ?l is a list which contains (does not contain) the element
> ?x, both arguments must be ground, can not be used as a generator.
>
> listEntry(?list, ?index, ?val)
> Binds ?val to the ?index'th entry in the RDF list ?list. If there is
> no such entry the variable will be unbound and the call will fail.
> Only useable in rule bodies.
>
> listLength(?l, ?len)
> Binds ?len to the length of the list ?l.
>
> listEqual(?la, ?lb)
> listNotEqual(?la, ?lb)
> listEqual tests if the two arguments are both lists and contain the
> same elements. The equality test is semantic equality on literals
> (sameValueAs) but will not take into account owl:sameAs aliases.
> listNotEqual is the negation of this (passes if listEqual fails).
>
> listMapAsObject(?s, ?p ?l)
> listMapAsSubject(?l, ?p, ?o)
> These can only be used as actions in the head of a rule. They deduce a
> set of triples derived from the list argument ?l : listMapAsObject
> asserts triples (?s ?p ?x) for each ?x in the list ?l,
> listMapAsSubject asserts triples (?x ?p ?o).
>
> [1] http://jena.apache.org/documentation/inference/#RULEbuiltins
>
> --
> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
>
Re: Access list values in rules
Posted by Joshua TAYLOR <jo...@gmail.com>.
On Mon, Aug 5, 2013 at 9:02 AM, Igor Brussilowski
<ig...@yahoo.de> wrote:
> Hi all,
>
> I'm looking for how to access list items in a reasoner rule. E.g the pattern (?S owl:kasKey ?L) returns a list of all matching objects. Is there any way to access here the elements of the list for further processing, e.g. to print them all out?
According to the documentation [1], there are a number of builtins for
working with lists:
listContains(?l, ?x)
listNotContains(?l, ?x)
Passes if ?l is a list which contains (does not contain) the element
?x, both arguments must be ground, can not be used as a generator.
listEntry(?list, ?index, ?val)
Binds ?val to the ?index'th entry in the RDF list ?list. If there is
no such entry the variable will be unbound and the call will fail.
Only useable in rule bodies.
listLength(?l, ?len)
Binds ?len to the length of the list ?l.
listEqual(?la, ?lb)
listNotEqual(?la, ?lb)
listEqual tests if the two arguments are both lists and contain the
same elements. The equality test is semantic equality on literals
(sameValueAs) but will not take into account owl:sameAs aliases.
listNotEqual is the negation of this (passes if listEqual fails).
listMapAsObject(?s, ?p ?l)
listMapAsSubject(?l, ?p, ?o)
These can only be used as actions in the head of a rule. They deduce a
set of triples derived from the list argument ?l : listMapAsObject
asserts triples (?s ?p ?x) for each ?x in the list ?l,
listMapAsSubject asserts triples (?x ?p ?o).
[1] http://jena.apache.org/documentation/inference/#RULEbuiltins
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/