Re: SHACL target extension

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 08:29:17 UTC