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

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.

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
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 30 September 2016 03:42:33 UTC