Hi Andy, Our jena-shacl use case in fuseki involves a limited set of graph types each with its own set of shapes, most of which do not apply to other graph types, although some apply across all graphs like requiring at least one skos:prefLabel from among a list of languages.
Each changed/new graph needs to be validated in the context of a comparatively small subset of all of the named graphs: the ontology graph, and graphs containing resources referenced from the subject graph. Pretty much your case: >> * the validation needs local changes (e.g. minCount) to the entity (subject >> and all triples with that subject) - that can be used to reduce the number >> of validations done. If a entity isn't touched, no validation necessary. We’re currently using ont-policy.rdf and imports to group shapes ontologies into graphs and provide an include facility. We have code that interrogates a custom element in the OntologySpec that is used to PUT a named shape graph to fuseki. So I’m not sure about the proposed features https://afs.github.io/shacl-datasets.html <https://afs.github.io/shacl-datasets.html>. I haven’t looked at shacl-c. Thank you, Chris > On May 20, 2020, at 2:50 PM, Andy Seaborne <a...@apache.org> wrote: > > Hi Ben, > > Not currently I'm afaird but certainly something to provide. > > Question to everyone: > > Would it work if the same SHACL rules applied to all graphs? Or are there > cases where different graph have different sets of shapes? > > It is possible to prune the validation work significantly because many > constraints don't need the whole dataset so having many shapes, most of which > don't apply to a graph should not have too much impact. > > What is more the validation is focused on changes: > > * the validation is only on the triple added (e.g. sh:datatype) - and does > not need access to the database so it can be done in parallel outside the > transaction. > > * the validation needs local changes (e.g. minCount) to the entity (subject > and all triples with that subject) - that can be used to reduce the number of > validations done. If a entity isn't touched, no validation necessary. > > * global - needs access to the whole database. Not much can be done except > execute inline at the end of the transaction. > > (from > https://lists.apache.org/thread.html/rc4df58fba718a0cbfe9305cee9ab24c6c25bc162c468f9336f059b85%40%3Cusers.jena.apache.org%3E > ) > > or does it need something more compliucated, may be even targeting graphs? > > https://afs.github.io/shacl-datasets.html > > Another thing to add is SHACL-C (Compact syntax), at least for reading, for > manageability in the case of many relatively simple constraints. > > Andy > > > > On 20/05/2020 13:08, Benjamin Geer wrote: >> Hello, >> Is it possible to configure Fuseki to use >> org.apache.jena.shacl.GraphValidation, so that each update is accepted only >> if, after the changes, the union of all named graphs in the dataset would be >> valid according to SHACL shapes that are configured on the server? In other >> words, to do what the Shacl02_validateTransaction example does, but for >> updates submitted to Fuseki? >> Ben >> --- >> Data and Service Center for the Humanities (DaSCH) >> University of Basel, Switzerland >> https://dasch.swiss <https://dasch.swiss/>
