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 13:48:10 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <ac57d805-8991-aea9-4daf-c95ecbb1f902@topquadrant.com>


On 30/09/2016 13:42, Karen Coyle wrote:
>
>
> On 9/29/16 7:47 PM, Holger Knublauch wrote:
>>
>>
>> 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.
>
> Ok, that makes sense, but this is one of the problems that I have with 
> this section in general - it mixes the requirements for the shapes 
> graph with the requirements for the validation report. Somehow those 
> have to be made clearer, and as I said (somewhere else, I'm losing 
> track, sorry) this section doesn't talk at all about the shapes graph 
> - yet the shapes graph is the source for some of the properties in the 
> report which are merely echo'd back without modification.
>
> If the properties are not mere echoes of how they were stated in the 
> shapes graph, then they really must use different property names. The 
> same property can't have two meanings. For example, rather than 
> combining sh:property and sh:path into sh:path (which violates the 
> semantics of that latter property) I would echo back each 
> individually. If they aren't mere echoes, then they need their own 
> properties.

Yes, I wonder about that too. We could make them disjoint, e.g.

sh:path -> sh:resultPath
sh:message -> sh:resultMessage
sh:severity -> sh:resultSeverity

(It's OK to have longer names there, because these are all 
machine-generated).

If you think this is helpful, could you file a new ISSUE because this 
would be more than an editorial change?

Thanks
Holger


>
> I also agree with Peter that the use of "may link to X" is 
> unfortunate, and is used throughout (it's the "link" part that is 
> problematic). To me it doesn't convey that the predicate listed takes 
> as its object the IRI of X. I'll think about that more, though, 
> because such a criticism should be followed by a viable suggestion, 
> and I don't have one at the moment.
>
>
>>
>>>
>>> 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?
>
> See my earlier email with a comment on "empty sets". And I don't see a 
> statement that no validation report is generated for successful 
> constraint comparison, which I think is implied.
>
> kc
>
>>
>> Thanks,
>> Holger
>>
>>
>>
>
Received on Friday, 30 September 2016 03:48:46 UTC

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