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

Thank you Arthur, is all clear now from my side.
I support your definitions on filter and scope.

Dimitris
On Jan 8, 2016 01:17, "Arthur Ryman" <arthur.ryman@gmail.com> wrote:

> 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
> >
>