On 29/04/2020 12:35, Nicola Vitucci wrote:
Hi all,
I am writing a blog post on this very subject (adding reasoning capabilities to
Fuseki datasets and more) and I got a similar behaviour when updating a named
graph. I've also used all the supported reasoners.
I look forward to reading it.
My solution is kind of intermediate: creating an RDFDataset with a default
graph that reasons on the special union graph, then several named graphs
containing my data, each one with its (named) inference graph. In this way it's
possible to add triples to the named inference graphs (as Andy suggested too)
and have them reasoned upon in real time, plus the default graph can reason
cross-graph (but it can only be updated with a restart anyway). I know it's not
ideal, but it can probably get what you need. I'll add more details as I put
things together.
@Andy: it would be nice if a dataset "reload" was supported via API as the
change of state (active/offline) is. Any thoughts on this?
The issue is when changes go in via one route but inference in a graph
is a different route. It's bypassing the rule machinery that exists that
already exists and works.
Where that breaks down is when the base graph is some kind of composite,
default union graph is one example but there could be other
combinations. The problem here is that the update coming through the
inference graph can not be directed to the right place. Which graph in
a union should be updated? Jena's union graph have one distinguished
graph to update (base data and inference deductions) but when using
named graphs for data management there isn't a distinguished single
place to pass on the updates to.
Currently, it is possible to intercept every update (see
DatasetGraphMonitor). This is how RDF Delta works; there's a class
called DatasetGraphChanges that logs every change and also hook itself
into the transaction lifecycle so changes are batched into transactions.
For inference, I've been asking what level of inference people are
really using. We could have a stateless RDFS-class reasoner that sits on
any graph/dataset and always goes back to the base data. No, or very
short term, caching.
That would be less capable, and slower (but how much? not much in
practice?) but it will scale, will fit with transactions and data
visibility, and will see changes in the data as they occur.
Another case is eTags which would help query caching. This is a simpler
test - adding a monitoring wrapper to a dataset is a rather heavy and
inflexible way to do it. Wrapping (layering) is all very well until the
order matters and two different wrappers want to be "first".
Knowing the generation of the data seems to me at the moment to be worth
adding to the dataset interface itself. A simple "what version am I
looking at?" method. It could be a counter (sequential) or give every
write transaction a UUID and be able to fetch the generation of the data
the current read transaction is acting on.
Andy
Any comments are welcome.
Nicola
On 2020/04/29 08:08:43, Andy Seaborne <[email protected]> wrote:
Sascha,
(aside)
For my general understanding:
What level of reasoning are you and your student interested in having?
There is a tradeoff between inference expressiveness, performance (CPU
and RAM costs), how much development effect it would take for future
improvements.
On 29/04/2020 08:18, Meckler, Sascha wrote:
Hello Andy and Marco,
the problem also applies to built-in reasoners.
I tried Jena's OWLFBRuleReasoner, OWLMicroFBRuleReasoner and the
RDFSExptRuleReasoner.
(See demo project:
https://github.com/smeckler/inference-demo/blob/master/src/main/resources/fuseki/config.ttl)
Each of which has some forward rules.
If you want to update the inference graph, send updates to the inference
graph.
Andy
Thank you for your help!
Best regards,
Sascha
-----Original Message-----
From: Marco Neumann <[email protected]>
Sent: Tuesday, April 28, 2020 7:12 PM
To: [email protected]
Subject: Re: Fuseki inference not triggered with incoming data
so Sascha in short try to use one of the Jena build-in reasoners if this is
not bound to a pellet specific task. if it is you will have to bring this
request up with the pellet maintainers.
On Tue, Apr 28, 2020 at 5:20 PM Andy Seaborne <[email protected]> wrote:
On 27/04/2020 09:49, Meckler, Sascha wrote:
Hi *,
I have a question about Fuseki:
We have a Fuseki server with one dataset for actual data and one dataset
with reasoning based on the default union graph (=data from first dataset).
When I insert new data into the first dataset, the inference is not always
triggered. The reasoning dataset updates only at the first time or when
restarting. How can we configurate Fuseki to run the inference every time
that new data is inserted into the first dataset? Or is there a better way
to do this?
For forward rules, I think that the data updates have to go through the
graph with the inference. Forward rules keep state so if you bypass
inference the graph, the state does not get updated.
Backwards rules may notice to some extent - I'm unsure of the details here.
Pellet isn't part of the Apache Jena project.
Andy
I created a small demo project with an easy example and additional
documentation [1]. My student asked on StackOverflow [2] in January but
there was no answer.
Thank you very much for your help!
Best regards,
Sascha
[1] https://github.com/smeckler/inference-demo
[2]
https://stackoverflow.com/questions/59952945/reasoning-in-apache-jena-
fuseki-reload-dataset-or-trigger-inference
______________________________________________________
Sascha Meckler
Data Spaces and IoT Solutions
Fraunhofer-Institut für Integrierte Schaltungen
<https://www.google.com/maps/search/tut+f%C3%BCr+Integrierte+Schaltun
gen?entry=gmail&source=g>
IIS
Nordostpark 93 | 90411 Nürnberg
Phone +49 911 58061-9614
--
---
Marco Neumann
KONA
