You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Dave Reynolds <da...@gmail.com> on 2023/02/01 08:53:32 UTC

Re: Builtin primitives in rule not triggered

On 31/01/2023 22:25, L B wrote:
> The current implementation only matches the triples when facts are
> updated.  

Correct, that's kind of the point of it.

> Do we have any plan to support built-in primitives?

? There are built in primitives and you can write your own primitives. 
That doesn't change the structure of rule evaluation

> such as the rule below, the rule will be evaluated when  uri1 or uri2 is
> updated.
> 
> [rule1:
> built-inName1(uri1, built-inName2(uri2)) -> xxxx
> ]

What does it mean to "update a uri"? Or match on one for that matter?

RDF is a set of triples, uris are just one of the types of atom that can 
be used to construct triples but don't themselves change. It's only 
facts about them that change. So if you want to fire some rule when a 
fact about either uri1 or uri2 changes then that's just:

(uri1 ?p1 ?o1), (uri2 ?p2 ?o2), f(uri1, uri2, ?result) -> x

The rule systems in Jena were developed to enable deductions to be made 
over a set of triples. If the base triples change the rules are supposed 
to figure out the new deduced triples. That's it.

They were designed to be relatively efficient when you are just adding 
more facts, and monotonic. So when you add more facts (triples) only the 
new facts need to be processed and you only get more deduced triples 
added, no old deductions gets removed. Over time we added some 
non-monotonic features (e.g. "remove", cough) because people found that 
useful but the system wasn't designed with the in mind and those 
non-monotonic features can be clunky.

If you are doing something too far outside this design centre then, as I 
said before, you may be better off using the generic listener events.

Dave

> 
> Dave Reynolds <da...@gmail.com> 于2023年1月28日周六 04:56写道:
> 
>> Once a rule has triggered it will only retrigger if the data changes in
>> a way that affects that rule's bindings. So a rule which doesn't match
>> anything on the LHS will not normally be retriggered.
>>
>> The behaviour you are seeing is as expected for the rule system.
>>
>> If your goal is to do something whenever data changes irrespective of
>> what the change is then you either need a rule with a pattern that will
>> match any data i.e. (?s ?p ?o) or don't use rules but use graph
>> listeners via the GraphEventManager interface.
>>
>> Dave
>>
>> On 27/01/2023 21:31, L B wrote:
>>> Thanks for the test code.
>>>
>>> Please correct me if I am wrong. Per the doc of listStatements:  Find all
>>> the statements matching a pattern.
>>>
>>> My problem is that when I update the facts, this rule is not be triggered
>>> (executed).  I assume this rule will be triggered every time when the
>> fact
>>> is updated.
>>>
>>> On the other hand, a leading triple can bypass it. For example
>>>
>>> [test1: (a b ?c) now(?x) -> print(\"now test\") ].   When you update
>> triple
>>> (a, b, xxx), the rule will be executed.
>>>
>>> Lorenz Buehmann <bu...@informatik.uni-leipzig.de> 于2023年1月26日周四
>> 23:13写道:
>>>
>>>> I cannot reproduce this. For example, the test code
>>>>
>>>>
>>>> public static void main(String[] args) {
>>>>            String raw = "<http://ex.org/a> <http://ex.org/p>
>>>> <http://ex.org/b> .";
>>>>            Model rawData = ModelFactory.createDefaultModel();
>>>>            rawData.read(new StringReader(raw), null, "N-Triples");
>>>>            String rules =
>>>>                    "[test1: now(?x) -> print(\"now test\") ]";
>>>>            Reasoner reasoner = new
>>>> GenericRuleReasoner(Rule.parseRules(rules));
>>>>            InfModel inf = ModelFactory.createInfModel(reasoner, rawData);
>>>>            System.out.println("A * * =>");
>>>>            StmtIterator iterator = inf.listStatements(null, null,
>>>> (RDFNode) null);
>>>>            while (iterator.hasNext()) {
>>>>                System.out.println(" - " + iterator.next());
>>>>            }
>>>> }
>>>>
>>>>
>>>> does in fact print "now test" to the console.
>>>>
>>>>
>>>> On 26.01.23 19:43, L B wrote:
>>>>> test1: now(?x) -> print("now test")
>>>>
>>>
>>
>