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 <dave.e.reyno...@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 <dave.e.reyno...@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 >
