"Preview Index" - additional, short-lived index for a few specific queries

[bradenmacdonald]

Hi @hannahbast. I read with great interest your proposed design for supporting UPDATE queries, and I can see you are actively working on it in recent PRs.

I have a possibly unusual use case, and was wondering if you think the same technical foundation you are building for UPDATE could be leveraged to support it.

In short, I want to send a handful of triples to QLever and then run SPARQL queries as if those triples were already added to the graph, as a way of "previewing" the update. But I don't want to actually commit them to the graph (yet). It seems to me like this is very similar to the "indexes A and B" of your design, it's just that in this case index B is very short-lived. Or perhaps there is index A (contains most of the triples) and B (contains any triples committed since the last full index rebuild), plus a short-lived index C (contains a few additional triples just for the current query, typically < 100).

---

For context:

I work on knowledge graph software that tries to make it easy for non-experts to contribute knowledge to the graph, much like anyone can edit Wikidata. But we often have the requirement that all changes are reviewed by a subject matter expert before they go live. So we essentially need "pull requests" for changes to the graph.

The reviewer sees a screen like this, and can then decide to accept the changes or ask for revisions, just like a pull request.

But, in order for the reviewer to effectively review, they need to see what the changes look like as displayed on an actual entry page in the UI, and how the changes may affect other related entities - because in the UI we display a lot of inferred properties.

For example, if someone opened a pull request to add information about a new gondola somewhere in the world, then on this page about aerial lifts, when I "preview" their changes to the graph, I would expect to see the new gondola listed in the inferred "Instances [of Aerial Lifts]" property, and if it had a higher capacity or speed than any other gondola currently in the graph, I would expect to see it show up in the text where it lists the records:

So it's extremely helpful if there's a way to preview such inferred properties (which would come from SPARQL queries) before deciding whether or not to accept the changes.

---

Anyhow, I'd love to hear your thoughts on whether or not it would be reasonable for me to build this sort of functionality on top of the multi-index work you're doing to support UPDATE. (This is not something I'll be working on soon, but hope to get to in the longer term.)