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 <[email protected]> 于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 <[email protected]> 于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")




Reply via email to