In vanilla RDF, you do not change 5 to 10, you either delete the 5 and add the 10 or you add the 10 then delete the five! Maybe it all happens in a transaction which might make the immediate states invisible to the outside world.
I use the Jena Rules engine with user defined functions that create side effects and it is a lot of fun: I write RDF -> X conversion systems this way, and also have an asynchronous execution engine. In both of these cases I conciously or unconciously make everything a latch so deletes do not happen, but it could be a problem if I want to use deletion, I would not want to run the side effecting methods again if I can at all help it. For the most part I *do not* apply inference rules to a transactional or archival database but rather I pull in one or more records and maybe some data tables and do some reasoning to answer a question about some topic and then use the answer or put it back in some database. I know Drools has better support for deletions, so does the RDF database from Ontotext. What would be involved in supporting this in Jena? -- Paul Houle [email protected] On Mon, Jan 9, 2017, at 02:57 PM, Dave Reynolds wrote: > Hi Claude, > > On 09/01/17 10:55, Claude Warren wrote: > > I am digging into reasoners for the first time in a long time and have a > > couple of questions. > > > > What I am trying to do is the following: > > > > Assume data: > > > > <x> <my:sameValue> <y> > > <y> <my:value> 5 > > > > I want a rule that will produce > > > > <x> <my:value> 5 > > So something like: > > (?x my:sameValue ?y) (?y my:value ?v) -> (?x my:value ?v) > > > but in addition if I change [<y> <my:value> 5] to [<y> <my:value> 10] I > > want the reasoner to change [<x> <my:value> 5] to [<x> <my:value> 10] > > > > So after first reasoning data are: > > > > <x> <my:sameValue> <y> > > <y> <my:value> 5 > > <x> <my:value> 5 > > > > and after changing <y> <my:value> 5 the data are: > > > > <x> <my:sameValue> <y> > > <y> <my:value> 10 > > <x> <my:value> 10 > > > > Note that the <x> <my:value> 5 has been deleted. > > > > Is this possible? > > Sure, it would work that way so long as the [<y> <my:value> 5] is only > present by virtue of the inference, not in the base graph (see below). > > > In general do rules recalculate the results when the data changes?-- > > Yes but deletes are not incremental, and the details differ between the > reasoners. > > The forward reasoners keeps a graph of partial bindings and if new > triples are added the additional inferred triples are computed > incrementally. If a triple is removed then the graph is marked unclean > (the "prepared" flag is reset) so at the next query (or next explicit > prepare() call) the inference will be restarted from scratch. > > So in your case, starting with a base model of: > > <x> <my:sameValue> <y> > <y> <my:value> 5 > > then the above rule would generate a deduction of: > > <x> <my:value> 5 > > If you then delete: > > <y> <my:value> 5 > > and add: > > <y> <my:value> 10 > > Then, at the next query, the forward reasoner will throw away its > deductions graph and internal rete network and start over, it would then > generate: > > <y> <my:value> 5 > > However, if your base graph had: > > <x> <my:sameValue> <y> > <y> <my:value> 5 > <x> <my:value> 42 > > then the rules won't remove that third triple so you would end up with: > > <x> <my:sameValue> <y> > <y> <my:value> 5 > <x> <my:value> 42 > <x> <my:value> 5 > > For the backward rules then, unless you use tabling to cache partial > goals, the inference is done on demand at query time anyway so you'll > get the same answers as above and the work will be done again at each > query whatever you've done to the graph in the meantime. > > Dave >
