Re: followup questions to Arthur's proposal regarding scope/filter (ISSUE-49)

Dimitris,

The short answer is that scopes determine R the initial set of
shape-node pairs (T,n) that a SHACL validator will check. The SHACL
validator will evaluate shape T on node n for all (T,n) that are in
scope. If no shape has a scope defined, then the validator has no work
to do so it simply returns an empty set of violations.

I'll simplify your example.

Let the data graph be:

<issue1> ex:reviewer <Dimitris> .


Case 1. The issue shape has a scope. The scope is all nodes that have
a ex:reviewer property, i.e. the scope is all subject nodes of triples
whose predicate is ex:reviewer.

<IssueShape> a sh:Shape ;
   sh:scope [ a sh:PropertyScope ; sh:predicate ex:reviewer ] ;
   sh:property [ sh:predicate ex:reviewer ; sh:minCount 1 ;
sh:valueShape ex:MaintainerShape ] .

<MaintainerShape> a sh:Shape ;
   sh:property [ sh:predicate ex:maintainer ; sh:hasValue true ] .

In this case the SHACL validator sees that <IssueShape> has a scope
and that <issue1> is in scope because it has a ex:reviewer property. R
= {(<IssueShape>, <issue1>)}. Therefore the validator will evaluate
<IssueShape> on <issue1>. But this fails because <Dimitris> violates
<MaintainerShape>.

Case 2. The issue shape has no scope but does have a filter:

<IssueShape> a sh:Shape ;
   sh:filterShape [ sh:property [ sh:predicate ex:reviewer ; sh:minCount 1]] ;
   sh:property [ sh:predicate ex:reviewer ; sh:minCount 1 ;
sh:valueShape ex:MaintainerShape ] .

<MaintainerShape> a sh:Shape ;
   sh:property [ sh:predicate ex:maintainer ; sh:hasValue true ] .

In this case there is no scope so there are no nodes to evaluate. R =
{ }. The SHACL validator produces no violations.

-- Arthur

On Thu, Jan 7, 2016 at 5:31 PM, Dimitris Kontokostas
<kontokostas@informatik.uni-leipzig.de> wrote:
>
>
> On Thu, Jan 7, 2016 at 11:58 PM, Arthur Ryman <arthur.ryman@gmail.com>
> wrote:
>>
>> I am forwarding my reply to the list using the corrected ISSUE number (was
>> 43).
>>
>> Dimitris,
>>
>> In fact, as far as I can tell, your example results in NO violations.
>> However, I believe that your intension is to make <issue1> and
>> <issue2> raise violations because their ex:reviewer properties do not
>> have "ex:maintainer true" values.
>
>
> Actually I didn't, you answer is perfectly fine for me, it is just that you
> definition was stating
> "With this definition, scopes and filters are independent features of SHACL.
> filters are always used when determining if a shape is satisfied."
> the last sentence was not clear in regard to my follow up questions.
> (see also below)
>
>>
>> I believe that what you want to achieve in this example is to say that
>> an issue is valid if its reviewer is a maintainer, which can be stated
>> directly without scopes or filters. Simply define MaintainerShape to
>> require the presence of the ex:maintainer property and further require
>> it to have the value "true". If you also want to say that all
>> reviewers must be maintainers then you can add a sh:PropertyScope:
>>
>> ex:MaintainerShape a sh:Shape
>>    sh:scope [
>>       a sh:PropertyScope ;
>>       sh:predicate ex:reviewer .
>>    ] ;
>>    sh:property [
>>       sh:predicate ex:username ;
>>       sh:minCount 1 ;
>>       sh:maxCount 1 ;
>>    ] ;
>>    sh:property [
>>         sh:predicate ex:maintainer ;
>>         sh:hasValue true ;
>>    ] .
>>
>> A SHACL validator takes as input a pair (S,D) where S is a shapes
>> graph and D is a data graph, and produces as output V a set of
>> constraint violations (let's ignore warnings, infos).
>>
>> The validation process starts by producing a set R ( these are the
>> requirements that must be satisfied), which is a set of pairs, (T,n)
>> where T is a shape in S and n is a node in D. A pair (T,n) is in R
>> whenever the following conditions are satisfied:
>> 1. n is in the scope of T as defined by sh:scopeClass, sh:scopeNode,
>> or a general scope, sh:scope. If there is no explicit scope then the
>> effective scope is the empty set.
>> 2. n satisfies the filter of T. If there is no explicit filter then
>> the effective filter passes all nodes, i.e. it is TRUE for all nodes.
>>
>> The above is clearly stated in the spec. The place where the spec is
>> unclear is if filters have any meaning outside their use with scopes.
>> My proposal is that we define the meaning of filters to be like an
>> IF-THEN operation. So it we need to evaluate a shape on a node, then
>> first we evaluate the filter. If TRUE then continue to evaluate the
>> other constraints. If FALSE then the shape is deemed to be satisfies,
>> i.e. no further constraint checking occurs and therefore no violations
>> are possible.
>
>
>
> I am not sure I still understand the difference between filters and scopes,
> Can you provide an example where
>
> sh:scope [
>       a sh:PropertyScope ;
>       sh:predicate ex:reviewer .
>    ] ;
>
> behaves differently from
>
> sh:filterShape [
>   sh:property [ sh:predicate ex:reviewer ; sh:minCount 1]]
>
> Dimitris
>
>>
>>
>> Your example does not take advantage of the proposed meaning of
>> filters. My proposal for filter makes it possible to define additional
>> constraints that only make sense when certain other conditions apply.
>> For example, suppose that your application defined the default value
>> for ex:maintainer to be true, i.e. if ex:maintainer is absent then
>> treat it as having the value "true". Then in ex:MaintainerShape you
>> want to say "IF ex:maintainer is present THEN its value must be TRUE":
>>
>> ex:MaintainerShape a sh:Shape
>>    sh:filterShape [
>>       sh:property [
>>          sh:predicate ex:maintainer ;
>>          sh:minCount 1 .
>>       ] .
>>    ] ;
>>    sh:property [
>>       sh:predicate ex:username ;
>>       sh:minCount 1 ;
>>       sh:maxCount 1 ;
>>    ] ;
>>    sh:property [
>>         sh:predicate ex:maintainer ;
>>         sh:hasValue true ;
>>    ] .
>>
>>
>> -- Arthur
>>
>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://http://aligned-project.eu
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: http://aksw.org
>

Received on Thursday, 7 January 2016 23:17:39 UTC