There is also something called SPIN (SPARQL Inferencing Notation). Can we use it as the best possible alternative of Jena rules?
On Thu, Aug 31, 2017 at 10:48 AM, Dave Reynolds <[email protected]> wrote: > On 30/08/17 15:10, [email protected] wrote: > > PS: I wonder why Dave doesn't comment in this thread. Perhaps because he >> thinks, Lorenz is ok, i myself cannot stand the low-level-knowledge of the >> users in this thread or no matter what you do, by some heavy data-input an >> app with InfModel would hang anyway? Lorenz is ofcourse ok, but i 'guess' >> Jena users are also very curious about Dave's comments... >> > > I didn't comment on this thread because, as Andy has already pointed out, > this seems to be a repeat of a recent similar thread (on which I did > comment). That in turn was a near repeat of another similar thread. All > from the same group. > > Also I think Lorenz has covered it all, with admirable patience. > > However, in an attempt to clarify the trade-offs in more depth maybe the > following would be helpful: > > When comparing a rule system against a set of SPARQL Update queries there > are several factors that affect the trade-offs including (1) the specific > nature of the rules/queries, (2) the data flow and, (3) preferences on > syntax and machinery. > > 1a. For a single (forward) Jena rule then you can always achieve the same > with a SPARQL Update. For a single set of input data then SPARQL has the > benefit of being a standard [1] and offering better performance over a > store like TDB. Conversely SPARQL is much richer than Jena rules so there > are things that you could achieve with a single SPARQL Update query using, > say, property paths that would require multiple Jena rules. > > 1b. If you have a set of rules, but they don't create loops/recursion, > then you can "stratify" them into groups of rules than can be run one after > the other. In that case, for a single set of input data, then again you can > implement it as a sequence of SPARQL Updates with similar benefits. > > 1c. If your rules can't be stratified, i.e. one rule can indirectly > trigger itself, then it's more complex. In that case you would have to e.g. > run the set of SPARQL Updates repeatedly until nothing new is deduced. > Depending on the specifics of the rules and the data that may be quite > expensive and you would be better off with something Jena rules. However, > in some cases you may be able to use things like SPARQL property paths to > achieve the desired effect without have to recurse. > > 2. If you have a single data set and just want to run your rules on it > then the above applies. If you are repeatedly adding new data and want to > keep your deductions up to date then the Jena forward rules engine has the > advantage that it keeps all the partial matches around. So addition of one > more triple may cause a rule to fire without it having to search for all > the other triples in the body. This is also why "recursive" rules work > relatively efficiently. > > This doesn't apply if you delete data. In that case Jena rules have to > start over and can't reuse state across data deletions. > > If you keeping changing your data but very rarely ask questions of it, and > then only limited questions, then Jena back rules have advantages. The > backward engine will only run the rules needed for the specific query. If > that's a lot fewer than the overall rules then that should be cheaper than > running a full forward deduction using SPARQL Updates. In this situation it > may be possible to achieve the same effects through SPARQL query (not > update) by query rewriting but that's a whole different ball game. > > 3. With Jena rules you have some prebuilt machinery for running the rules > (InfGraphs and all that) and some support for externalizing the rules in > separate files. With SPARQL you have to create all that (though it's easy) > and you have a nicer syntax. > > So fundamentally, like all "X vs Y" questions it depends on the specifics > of what you are trying to do. > > Dave > > [1] There is a standard for rules, RIF, but it is not aimed at > particularly RDF processing and post-dates Jena rules. >
