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 >