SHACL target extension

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

Received on Tuesday, 19 May 2020 15:39:27 UTC