> > > On 08/07/2019 16:28, Aaron Coburn wrote: > >> Thanks, Andy, I will likely have some data+shape resources in the coming > >> weeks/months that I would like to test. Are there plans to add this > >> code to > >> Jena itself, or do you anticipate that it will be part of a separate > >> repository? > > Is your comment a preference to have it as part of the Jena distribution? > > (Anything to test with at the moment?) >
I was mostly curious about the plans for this code. I can't say that I have a strong preference: at the moment, I am primarily interested in having some code to test with. The fact that it is now in the Jena source tree will make this easier for me. Thanks, Aaron >> On Mon, 8 Jul 2019 at 10:58, Andy Seaborne <[email protected]> wrote: > >> > >>> I've got a SHACL validation engine working - it covers both the core > and > >>> sparql constraints of the W3C Specification. > >>> > >>> If anyone has data+shapes, I'll happily use them to run further tests. > >>> > >>> Status: passes the WG test suite except for some in > >>> std/sparql/pre-binding/. Optional $shapesGraph and $currentShape are > not > >>> supported (more below) and the "unsupported" tests in pre-binding (some > >>> of the rules seem overly restrictive) aren't run. > >>> > >>> AKA All valid shapes work, invalid shapes are "what you can get away > >>> with". This is for future flexibility :-) > >>> > >>> None of the non-spec SHACL-AF is covered. > >>> > >>> API: > >>> > >>> As well as the operations to validate a graph using a given shapes > graph > >>> (command line or API), there is also a graph that rejects > non-conforming > >>> data in a graph transaction. > >>> > >>> Datasets: > >>> > >>> SHACL is defined to validate a single graph. To extend to validation of > >>> a dataset, just one set for shapes for all graphs seems a little > >>> restrictive. > >>> > >>> Some ideas -- https://afs.github.io/shacl-datasets.html > >>> > >>> $shapesGraph is for the case where data and shapes are in one dataset - > >>> I'm not sure that's a very good idea because it imposes conditions on > >>> extending SHACL to data datasets. > >>> > >>> Opportunities: > >>> > >>> There are possibilities for further work for deeper integration into > >>> dataset update path: > >>> > >>> * Parallel execution - some shapes can be applied to an update stream > >>> without reference to the data so can be done on a separate thread > >>> outside the transaction. > >>> > >>> * Restricting the validation work needed - for some shapes > >>> (not all, but it is a static analysis of shapes to determine which) > >>> the updates can be tracked to only validate changes. There are ways to > >>> write shapes that (1) apply globally to the data or (2) have indirect > >>> data changes where just looking at the data does not tell you if a > shape > >>> might now report violations. > >>> > >>> There is some prototyping done but I got sidetracked by > >>> shacl-datasets.html > >>> > >>> Andy > >>> > >> >
