Hello Martynas,

I have no experience with implementing a validation layer for Fuseki.

But I might have an idea for your suggested approach:
Instead of loading a copy of the graph and modifying it, you could create
an org.apache.jena.graph.compose.Delta based on the unmodified graph.
Then apply the update to the delta graph and validate the SHACL on the
delta graph. If the validation is successful, you can safely apply the
update to the original graph and discard the delta graph.

You still have to deal with concurrency. For example, the original graph
could be changed by a second, faster update while you are still validating
the first update. It would not be safe to apply the validated changes to a
graph that has been changed in the meantime.

Arne




Am Mi., 13. Dez. 2023 um 14:29 Uhr schrieb Martynas Jusevičius <
marty...@atomgraph.com>:

> Hi,
>
> I have an objective to only persist constraint-validated data in Fuseki.
>
> I have a proxy layer that validates all incoming GSP PUT and POST
> request graphs in memory and rejects the invalid ones. So far so good.
>
> What about SPARQL Update requests though? For simplicity's sake, let's
> say they are restricted to a single graph as in GSP PATCH [1].
> What I can think of is first loading the graph into memory and
> executing the update, and then validating the resulting graph against
> SHACL. But maybe there's a smarter way?
>
> Also interested in the more general case without the graph restriction.
>
> Martynas
>
> [1] https://www.w3.org/TR/sparql11-http-rdf-update/#http-patch
>

Reply via email to