Re: shapes-ISSUE-182 (Validation report): [Editorial] Clarifications need to section 3.0

On 30/09/2016 10:24, Karen Coyle wrote:
>
>
> On 9/29/16 8:40 AM, RDF Data Shapes Working Group Issue Tracker wrote:
>> shapes-ISSUE-182 (Validation report): [Editorial] Clarifications need
>> to section 3.0
>>
>> http://www.w3.org/2014/data-shapes/track/issues/182
>>
>> Raised by: Karen Coyle On product:
>>
>> Section 3.0 on validation talks about the validation results, but
>> doesn't explain clearly which properties are required and which are
>> optional. It also should refer to the shapes graph as the source of
>> the properties, not just to their appearance in the report. Some
>> examples:
>>
>> "3.4.1.3 Value (sh:value)
>>
>> Validation results may have a value for the property sh:value
>> pointing at a specific node that has caused the result."
>>
>> - it isn't clear if sh:value MUST be returned if sh:value is coded in
>> the constraint, or if echoing back sh:value when it exists is itself
>> optional.
>>
>> 3.4.1.8 Declaring the Severity of a Constraint uses "can" not "MAY",
>
> The other recent email regarding validation reports (from Jose) made 
> me realize this:
>
> 3.4.1.7 - "Each validation result must have exactly one value for the 
> property sh:severity."
>
> then
>
> 3.4.1.8 - " sh:Violation is the default if unspecified."
>
> It isn't possible for sh:severity to be both mandatory and 
> unspecified. The value of sh:severity could be unknown (which would be 
> an error), but it cannot be unspecified. If sh:severity is not 
> supplied, that would also be an error. I suppose that in the case of 
> such errors one could default to sh:Violation, but that isn't what is 
> said here.

Hi Karen,

(if you look at the new version, I have made an editorial change to pull 
the indentation of section 3.4.1 up by one level, and as a result the 
section numbers have changed. Below I use the old numbers).

In 3.4.1.7, sh:severity is described and used for validation results 
(results graph).
In 3.4.1.8, sh:severity is described and used for constraint definitions 
(shapes graph).

Both cases use the same property IRI, which may or may not be a good 
idea. But in any case, they play different roles and are even used in 
different graphs. I have tried to clarify this distinction here:

https://github.com/w3c/data-shapes/commit/43a8d3e508f6485af357c93b6fcb137223e5f4cd

So: currently sh:severity is mandatory in validation results, but 
optional in constraints. I believe that's a reasonable approach because 
validation results are always machine generated, while we want to keep 
constraint definitions uncluttered.

>
> Would a better solution be to make sh:severity optional, which would 
> then also allow for the T/F case?

I am not sure what you mean with the T/F case. Could you clarify where 
you see problems?

Thanks,
Holger

Received on Friday, 30 September 2016 02:47:46 UTC