Hi,
On 03/04/2020 15:38, Benjamin Geer wrote:
I’ve been reading the documentation and list archives about Fuseki assembler
configurations with TDB and reasoners, and I’m trying to figure out whether the
setup I’d like to use is possible. I have three questions:
1. I’d like to use a forward-chaining reasoner to improve query performance
with a large TDB dataset by inferring some frequently queried relations. To
avoid having to recompute all the inferred triples every time Fuseki is started
(which could take a long time), I’d like to persist the inferred triples in TDB
as well. Is that possible? I looked for this scenario in the Jena documentation
but didn’t find it.
Basically this isn't supported, sorry.
The forward chaining engine keeps a *lot* of state in memory in the
RETE-like network. Which means unless you have very selective patterns
in your rules you can end up with large parts of the data in memory. In
worst cases you can have multiple copies.
This has several implications:
First, it means that it's not scalable. If you have a very large TDB
dataset then the reasoner is likely to run out memory. Plus the internal
format is really not optimised for large scale data and inference speed
will take a hit.
Second, it means that there's no point persisting the inference results
on their own, unless they are static. If, as in your case, you want to
continue to add new data and get incremental inferencing then you would
need some way to preserve and restore the intermediate state in the
engine, which is not supported.
So given this there's little point in supporting having the deductions
graph in TDB because that doesn't solve the problems of scaling and restart.
2. For queries, I’d like a default graph containing the union of all named
graphs plus the inferred statements. Can this be done along with (1)?
The first part can be done manually but not along with (1).
It's possible to use some offline process to generate a static set of
inferences (whether using the rule engine or e.g. SPARQL construct
queries) to one named graph, put the data in another graph and then have
the default graph be the union.
However, your data isn't static so this doesn't help.
3. The named graphs in the base model need to be continually updated (always
using SPARQL quad patterns), and I’d like the reasoner to update its inferences
when that happens. After reading some old messages on this list, I think this
might not be possible, because if I understand correctly, the only way to
update the base model would be via a separate Fuseki service that updates the
underlying TDB dataset directly, and in that case, the reasoner won’t see those
updates until Fuseki is restarted. Did I understand that correctly, and if so,
is it still true?
I thought you could configure fuseki to have a reasoner as the source
model and so have updates do to the reasoner rather than a base graph.
However, given none of the rest of what you need to do is supported this
point is moot.
Sorry to not be able to support your use case.
Dave
