Re: Review of SHACL document (2)

On 20/02/2017 23:15, Olivier Corby wrote:
> Hi,
>
> Some more comments on the SHACL document.
>
> Regards,
>
> Olivier
>
>
>
>
> 1.6 Relationship between SHACL and SPARQL
>
> SPARQL variables using the $ marker represent external bindings that 
> are pre-bound or, in the case of $PATH, substituted in the SPARQL 
> query before execution.
>
> The distinction between pre-bound and substituded is not clear.
> Is $PATH limited to predicate or does it accept property path ?
> In this latter case, what is substituted to $PATH ?

This is explained in section 6.3:

prior to execution substitute the variable|PATH|where it appears in 
thepredicate <#dfn-predicate>position of atriple pattern 
<https://www.w3.org/TR/sparql11-query/#QSynTriples>with a valid SPARQL 
surface syntax string of theSHACL property path 
<#dfn-shacl-property-path>specified via|sh:path|at theproperty shape 
<#dfn-property-shape>.

I have added a cross-reference from 1.6 to 6.3 to help future readers 
find this easier.

>
>
>
>
> 4.7.3 sh:qualifiedValueShape, sh:qualifiedMinCount, sh:qualifiedMaxCount
>
> There is no definition for sh:qualifiedValueShapesDisjoint

I remember you had raised this before and you had suggested to add

https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Feb/0036.html

If I am adding the statements you propose, it is quite possible that 
someone else will find issues with that statement or find it unclear. I 
am at this stage very hesitant to add any content that is redundant and 
in particular prone to logic errors or misunderstanding. I believe the 
property is already sufficiently defined, similar to how other 
properties are defined: by the textual definitions and syntax rules. Do 
you believe your statement adds any normative content that isn't already 
in the document?

(As a meta comment, we do have a pretty strict deadline of having to 
reach CR status by end of March. I need to balance all comments on 
whether they may stir up new issues. Unless absolutely essential, I 
would rather not make such changes. I hope it is in the best interest of 
everyone to give the WG a realistic path to reaching this goal, even if 
this means not getting the 100% perfect document from anyone's 
individual point of view).

>
>
>
> SHACL SPARQL
>
>
> 5.1 An Example SPARQL-based Constraint
>
> The following example illustrates a similar scenario as above, but 
> with a property shape.
>
>     sh:path ex:germanLabel ;
>
>     $this $PATH ?value .
>
>
> What happens when the value of sh:path is a property path that is not 
> a predicate ?

See 6.3 as quoted above - it inserts valid SPARQL surface syntax.

>
>
>
>
>
> 6.2.3.1 SELECT-based Validators
>
>
> First one has to guess that there is a relation between 
> ex:LanguageConstraintComponentUsingSELECT
> and ex:LanguageExampleShape because the former uses sh:parameter 
> [sh:path ex:lang] and the latter uses sh:property [ex:lang "de"].
> This is not very explicit.

Do you have specific suggestions on how to make this clearer?

>
> What happens if there are several such sh:ConstraintComponent with 
> sh:parameter [sh:path ex:lang] ?
> Do we apply all of them ?

Yes.

>
>
> Second, I find unclear to use sh:path in the sh:parameter statement 
> because 1) sh:path is usually used to specify a path in the target RDF 
> grapĥ (not in a shape)

We are using sh:path because sh:Parameter is a subclass of 
sh:PropertyShape. This has the nice side effect that the definitions of 
constraint components can more easily be used for checking the syntax of 
shapes and may use any other constraint parameter there too, e.g. 
sh:nodeKind. Each parameter declaration may therefore also be used as a 
shape.

> and 2) the SPARQL query in the sh:propertyValidator use a $PATH 
> variable that does not relate to this occurrence of sh:path.

That's correct. I don't see what to do about this though. Since you have 
gone through the efforts of trying to implement this, maybe you have 
specific suggestions on how this can be better explained. Again, we are 
very late in the process, so I am forced to try to avoid making any 
substantial changes to how this machinery works.

>
> Third, it is not specified whether  sh:datatype and sh:minLength in 
> the sh:parameter act as a constraint that must be verified by ex:lang 
> or as a condition that must  evaluate to true on ex:lang in order to 
> select and apply the sh:ConstraintComponent.

This is the topic of syntax checking, see above and in parallel email 
threads of this mailing list. There is currently no mandatory need to 
use these constraints but at least they do provide the infrastructure 
for those implementations that use SHACL to perform syntax checking 
(like TopBraid, see dash.ttl and tosh.ttl).

Thanks
Holger