W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > September 2016

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

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 30 Sep 2016 12:47:14 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <3534c6f1-12ca-35fa-89ec-d73d5d4f1fc0@topquadrant.com>

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:
>> " 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.
>> Declaring the Severity of a Constraint uses "can" not "MAY",
> The other recent email regarding validation reports (from Jose) made 
> me realize this:
> - "Each validation result must have exactly one value for the 
> property sh:severity."
> then
> - " 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, sh:severity is described and used for validation results 
(results graph).
In, 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:


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?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:36 UTC