Re: SHACL target extension

Hi Andy and Dimitris

Filters look like particularly useful constructs. They also look very powerful, which is both good and bad.

It’s quite close to what I want. I would want to have the filter run on all nodes in the data graph, essentially a sh:targetAllSubjects target. I think I saw something along those lines already, but I couldn’t find it now while writing this email. 

I can see that a natural extension would be to allow filters to be used as targets themselves, maybe through the SHACL Advanced sh:target property. 

Håvard

> On 20 May 2020, at 10:29, Andy Seaborne <andy@apache.org> wrote:
> 
> Nice!
> 
> That would be a useful addition to SHACL both on targets and on property shapes. And for rules.
> 
> Were there any other features that got dropped that the community might be interested in?
> 
>    Andy
> 
> 
>>> On 19/05/2020 22:29, Dimitris Kontokostas wrote:
>> Hi Håvard,
>> I think what you are after is something like the filter shape feature (https://www.w3.org/TR/2016/WD-shacl-201608Håvard14/#filterShape <https://www.w3.org/TR/2016/WD-shacl-20160814/#filterShape>)
>> This is something that existed in the first versions of SHACL but was dropped due to time restrictions near the end of the WG
>> Best,
>> Dimitris
>>> On Tue, May 19, 2020 at 11:05 PM Håvard Ottestad <hmottestad@gmail.com <mailto:hmottestad@gmail.com>> wrote:
>>   Hi James and Irene,
>>   Thanks for the replies.
>>   This is more a question of the standardisation aspect. Did anyone
>>   discus including more elaborate target building blocks? There is
>>   already sh:targetClass for rdf:type, but did anyone consider other
>>   class constructs like skos:inScheme?
>>   We already have two functional solutions within the current syntax:
>>    - use sh:targetNode with sh:inverseProperty
>>    - use SPARQL targets
>>   The issue with these solutions are:
>>   1. Using sh:targetNode and sh:inverseProperty are much harder to
>>   read than something like the compound target that we we
>>   considering introducing.
>>   2. SPARQL targets take took long to evaluate for transactional
>>   workloads.
>>   Håvard
>>>   On 19 May 2020, at 20:37, James Hudson <jameshudson3010@gmail.com
>>>   <mailto:jameshudson3010@gmail.com>> wrote:
>>>   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 <mailto: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
>> --
>> Kontokostas Dimitris

Received on Wednesday, 20 May 2020 10:25:44 UTC