Re: SHACL target extension

You may want to check out:

https://stackoverflow.com/questions/61323857/what-is-the-difference-between-these-shape-graphs-which-use-shor

and

https://stackoverflow.com/questions/61190422/validating-that-every-subject-has-a-type-of-class

and other SHACL questions and answers I have on SO. They may help you out.

As Irene already pointed out, SPARQL-based targets will solve your problem.


On Tue, May 19, 2020 at 11:39 AM Håvard Ottestad <hmottestad@gmail.com>
wrote:

> Hi,
>
> I’m the developer for the RDF4J SHACL implementation and we are looking
> into extending the targeting options in SHACL and are wondering if this is
> something that was discussed during the development of the standard or if
> anyone else has run into similar requirements.
>
> Essentially extending the current list of sh:targetNode, sh:targetClass,
> sh:targetSubjectsOf and sh:targetObjectsOf.
>
> Our use case can be summed up as.
>
> ex:Håvard ex:nationality ex:Norway;
>     ex:norwegianID “12345612345”.
>
> Where we would essentially like to be able to add a shape that says that
> all Norwegian citizens should have a Norwegian ID number.
>
> We have been testing out the concept of a compound target. For our current
> tests we have used our own namespace like this:
>
> @prefix rdf4j-sh: <http://rdf4j.org/schema/rdf4j-shacl#> .
>
> ex:PersonShape
>        a sh:NodeShape  ;
>        rdf4j-sh:compoundTarget [
>                rdf4j-sh:targetPredicate ex:nationality;
>                rdf4j-sh:targetObject ex:Norway
>        ];
>        sh:property [
>               sh:path ex:norwegianID ;
>               sh:minCount 1 ;
>               sh:maxCount 1 ;
>        ] .
>
>
> We have also been thinking about allowing rdf4j-sh:targetObject to be have
> multiple values.
>
> I also realise that it’s possible to use inversePath to solve this same
> problem, but I feel it becomes hard to read and grasp the intent.
>
> ex:PersonShape
>        a sh:NodeShape  ;
>        sh:targetNode ex:Norway;
>
>        sh:property [
>               sh:path [sh:inversePath ex:nationality ];
>               sh:property [
>                 sh:path ex:norwegianID ;
>                 sh:minCount 1 ;
>                 sh:maxCount 1 ;
>               ]
>
>        ] .
>
> Concurrently we have been testing the SHACL Advanced SPARQL targets. These
> allow us to do the same thing, but we are unable to achieve the same level
> of performance. In one of our benchmarks we see that SPARQL targets is 450x
> slower per transaction than compound targets. This is mostly due to our
> SHACL implementation being able to analyse the transactional changes and
> run a very minimal validation for compound targets. We do think that SPARQL
> targets could be considerably faster, but the design choices that allow for
> minimal transactional validation are currently also limiting our options
> for speeding up SPARQL targets.
>
> Does anyone know if this approach to a more flexible targeting has been
> considered as part of the spec? Or if someone has run into similar needs
> and is maybe considering implementing something similar.
>
> Cheers,
> Håvard
>
>
>
>