Re: validation results and validation reports

On 16/03/2017 0:39, Peter F. Patel-Schneider wrote:
> On 03/14/2017 05:37 PM, Irene Polikoff wrote:
>> Peter,
>>
>> This is a partial response. Please see below.
>>
>> Irene
>>
>>> On Mar 14, 2017, at 9:29 AM, Peter F. Patel-Schneider
>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>
>>>
>>> Some of the wording in the SHACL document still talks about producing
>>> validation results and needs to be adjusted.
>> I found only two instances of the word “producing”:
>>
>> In section 3
>>
>>   Conformance checking
>> <https://www.w3.org/TR/shacl/#dfn-conformance-checking> is a simplified
>> version of validation, producing a boolean result.
>>
>> and section 6.3
>>
>> As the first step, a validator
>> <https://www.w3.org/TR/shacl/#dfn-validators> must be selected based on the
>> rules outlined in 6.2.3 Validators
>> <https://www.w3.org/TR/shacl/#constraint-components-validators>. Then the
>> following rules apply, producing a set of solutions
>> <https://www.w3.org/TR/shacl/#dfn-solution> of SPARQL queries:
>>
>> Are you unhappy about the first sentence or about both of them and what would
>> you see as better wording?
> You can't look for just "producing".  Natural language doesn't work that way.
>
>
> A quick check of the current version of the document finds the following
> passages in the SHACL Core sections that almost certainly need to be
> adjusted:
>
> Furthermore, the validators always produce new result nodes, i.e. when the
> textual definition states that "...a validation result MUST be produced..."
> then this refers to a distinct new node in a results graph.
>
> If an ASK query does not evaluate to true for a value node, a validation
> result is produced based on the rules outlined in the section on ASK-based
> validators.
>
> If the comparison cannot be performed, then the SHACL processor will
> produce a validation result.
>
> If a value node is violating the constraint, sh:node will produce only a
> single validation result for this value node, with
>
> On the other hand side, sh:property may produce any number of validation results,
>
> The produced validation result MUST have the predicate of the triple as its
> sh:resultPath, and the object of the triple as its sh:value.
>
>
> There are also other passages that probably need to be adjusted:
>
> This is the focus node that was validated when the validation result was
> produced.
>
> For results produced by a property shape, this path is equivalent to the
> value of sh:path of the shape.
>
> For example, results produced due to a violation of a constraint based on a
> value of sh:minCount would have the source constraint component
> sh:MinCountConstraintComponent.
>
> If a shape has at least one value for sh:message in the shapes graph, then
> all validation results produced as a result of the shape
>
> The value of sh:conforms is true if and only if the validation did not
> produce any validation results.
>
> For every validation result that is produced by a validation process (except
> those mentioned in the context of conformance checking),
>
> Note that these validators define the only validation results that are being
> produced by the component.
>
>
> The above are likely to not be a complete list of passages that need to be
> adjusted.
>
>
> When changes are made to the SHACL document the rest of the document needs
> to be examined to see if there are further changes needed.  This does not
> appear to have happened here.

I did another pass through the document and updated several of these, 
including many of the above

https://github.com/w3c/data-shapes/commit/9f96654b6d3cf0c13294a4b0f8f1ffface9d4c1c

Overall (as a general response to this thread), I believe the intended 
semantics are sufficiently clear now. I do not want to make further 
passes through this over and over again, especially with our strictly 
limited time line. I believe the most reasonable way to proceed at this 
stage is to expose SHACL to implementers. We have the prose in the spec, 
which is written in natural language and thus always carries a slight 
risk of being misinterpreted, especially by readers that try very hard 
to find such little gaps. The same applies to any W3C spec. But we also 
have examples and (will have) test cases that clarify the contracts. In 
the opinion of the WG these things together should be enough information 
to make sure that SHACL can be consistently implemented by multiple 
organizations. We can revisit the wording once we have more evidence 
that implementers are confused.

What we are delivering here is the most realistic outcome based on our 
best efforts. We have certainly spent a lot of time word-smithing now 
and argued back and forth about the usual problems between a node and 
its "real world" resource, yet I believe we have gone beyond the point 
of diminishing returns. For some readers it will never be perfect. Other 
readers have long argued it is good enough to be put into production. 
It's a balancing act, if not an impossible mission, to make everyone happy.

>
>
>
>>> Validation of a focus node against a shape depends on "the validation of the
>>> focus node against all constraints declared by the shape".  "A shape in a
>>> shapes graph declares a constraint of kind c if c is a constraint component
>>> and the shape has values for all mandatory parameters of c."  However, this
>>> ignores situations where a shape as multiple values for parameters of
>>> constraint components that have a single parameter.  This is correctly
>>> overridden in the next paragraph, but the incorrect should be corrected.
>>> Then there is "The interpretation of such declarations is conjunction,
>>> i.e. all constraints apply." which is redundant.
>>>
>> Hmm… I re-read this part of section 2.1.1 and I think it reads well and the
>> meaning is clear. I suppose it is possible to change the first sentence so
>> that it conveys both ideas together, but I can’t think of how to do so without
>> creating a very convoluted, hard to parse sentence.
>>
>> If you have suggestions, please provide.
> https://arxiv.org/abs/1702.01795 has the following wording, which I think
> works well.
>
> For a constraint component C with mandatory parameters p1 , ..., pn, a shape
> s in a shapes graph S has a constraint that has kind C with mandatory
> parameter values <p1,v1>, ..., <pn,vn> in S when s has vi as a value for pi
> in S.

Ok, see

https://github.com/w3c/data-shapes/commit/cafcef4cadf8d581bdfeca9ed0064a496eeed435

Holger


>
> Peter F. Patel-Schneider
> Nuance Communications
>
>

Received on Friday, 17 March 2017 00:55:52 UTC