You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Benjamin Geer <be...@dasch.swiss> on 2020/05/20 12:08:16 UTC
SHACL validation of updates with Fuseki
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/>
Re: SHACL validation of updates with Fuseki
Posted by Benjamin Geer <be...@dasch.swiss>.
Hi Andy,
Would it work if the same SHACL rules applied to all graphs?
>
That would be fine for us.
>
> * 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.
>
Ideally we'd want some of each, but we'll be glad to take whatever ends up
having acceptable performance in our use case. Any validation would be
better than no validation.
Ben
Re: SHACL validation of updates with Fuseki
Posted by Chris Tomlinson <ch...@gmail.com>.
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 <an...@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/>
Re: SHACL validation of updates with Fuseki
Posted by Andy Seaborne <an...@apache.org>.
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/>
>