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

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.

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.

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

Received on Thursday, 7 January 2016 21:58:59 UTC