I'd like to offer it to Jena or the community wants and will engage
with. The Jena development cycle isn't a problem here.
https://github.com/afs/morph
migrated to:
https://issues.apache.org/jira/browse/JENA-1733
and
https://github.com/afs/jena/tree/shacl
if anyone wants to try it out right now.
This should be considered "experimental" for a release or so to allow
for naming and APIs to be tweaked based on feedback/experience.
** A SHACL API
https://github.com/afs/jena/tree/shacl/jena-shacl/src/main/java/org/apache/jena/shacl
including GraphValidation.validation which executes a graph transaction
and aborts on validation failure.
Not included: https://afs.github.io/shacl-datasets.html
** SHACL comment line tool
shacl --shapes shapes.ttl --data data.ttl
and also optional argument "--text" for a compact text output format.
** Fuseki service
POST a shape graph to
http://.../ds/shacl?graph=
where the ?graph is "default" (which is the default for no ?graph), or
"union" or a graph URI and get back a validation report.
The validation service is wired into Fuseki like the core SPARQL
operations. :-( and is the motivation for something more flexible:
https://issues.apache.org/jira/browse/JENA-1731
but to do JENA-1733 properly may take a some time and some replumbing of
Fuseki dispatch so to avoid a hold-up, it is wired in directly at the
moment.
An RDF patch service for RDF Delta would also like to have an extension
mechanism.
Andy
On 08/07/2019 16:28, Aaron Coburn wrote:
Thank, 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?)
Best,
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
