Re: Review of SHACL document (2)

Hi Olivier, (and others)

our W3C process requires that we try to get feedback from reviewers on 
whether their issues have been addressed. Since you had started a couple 
of email threads here, please let us know if there are any remaining 
items that have not been addressed to your satisfaction (or at least 
whether you "can live" with the given responses).

Thanks!
Holger


On 21/02/2017 11:56, Holger Knublauch wrote:
>
>
> 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
>