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

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