Does Comunica support any kind of "live"/reactive querying?

[Peeja]

I'm a little new to RDF, so I may be a bit fuzzy on what I'm even asking about.

I'd like to build a React app and back it with queries to Comunica, much as I might back it with GraphQL queries to Apollo. If I have queries over local data, say in Quadstore, is there a good way to open a "live" query through Comunica and stream in data as it updates? That is, given the data from the SPARQL Overview Example, can I query Comunica with something like:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name (COUNT(?friend) AS ?count)
WHERE { 
    ?person foaf:name ?name . 
    ?person foaf:knows ?friend . 
} GROUP BY ?person ?name

in one component, and read off the following results:

?name	?count
"Alice"	3
"Bob"	1
"Charlie"	1

then elsewhere in the app add the triples:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<http://example.org/bob#me> foaf:knows <http://example.org/charlie#me> .
<http://example.org/charlie#me> foaf:knows <http://example.org/bob#me> .

and have some kind of event back at my original query now give me:

?name	?count
"Alice"	3
"Bob"	2
"Charlie"	2

?

A naive way to do this would be to watch for any update to the store and rerun the query. But that's expensive because a) the data added to the store may be unrelated to the query, and b) rerunning the query (presumably) recomputes partial results that could theoretically be reused between queries.

Is there an efficient way to accomplish this today? If not, is there any plan for it, or an obvious way to extend Comunica to support it? Or would this be beyond the scope of the project?

[rubensworks]

That's an interesting question!

What you may be looking for is called RDF Stream Processing (RSP), which allows continuous querying over data streams (possibly over moving time windows).
This is something that is unfortunately not possible at the moment with Comunica.
Architecturally, RSP support can definitely be added, it would just require some implementation effort.
It's not on the roadmap at the moment, but contributions are definitely welcome.

As you said, an alternative approach is indeed rerunning the whole query upon data changes.
But this may indeed be less efficient, but shouldn't be too big of a problem for smaller datasets.
If you follow this route, make sure to invalid the internal cache when needed.

[Peeja]

Thanks!

It looks like RSP hasn't had much activity lately. Is the conversation still happening somewhere else?

I'll try just having the query rerun and see if it's actually a performance issue at my scale. It might be fine.

Are there any other levels I can cache the intermediate results at right now, or just at HTTP requests? I'm sure that's the biggest thing by far, but if there was some complex joining happening in the query over rarely-changing data (or data known to be monotonic), that might be theoretically cacheable and save some computation.

[rubensworks]

It looks like RSP hasn't had much activity lately. Is the conversation still happening somewhere else?

Indeed, not much activity AFAIK. There is a community group, but it has gone stale: https://www.w3.org/community/rsp/

Are there any other levels I can cache the intermediate results at right now, or just at HTTP requests?

Not at the moment, no.
I'm sure there are plenty of opportunities there though, such as at the level of joins as you have mentioned.