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

On 7/10/2016 7:36, Karen Coyle wrote:
>
>
> On 10/5/16 8:58 PM, Holger Knublauch wrote:
>>>>>
>>>>> 3.4.1.8 Declaring the Severity of a Constraint uses "can" not "MAY",
>>>>> and gives the default as sh:Violation (Does that mean T/F cannot have
>>>>> a default?). Better wording would be:
>>>>>
>>>>> "The severity level of a constraint violation MAY be coded in the
>>>>> constraint of a shapes graph using the property sh:severity, which
>>>>> takes as its value one of the SHACL pre-defined severities, or a
>>>>> locally defined severity." (followed by remaining sentences)
>>>>
>>>> I have applied similar wording to 3.4.8.
>>>
>>> I don't see changes in those sections - did the changes actually go in?
>>
>> I did not use your exact wording, but please verify whether you can live
>> with 3.4.8 and 3.4.9 now. I didn't use the term "locally defined
>> severity" because it will open more questions such as "in which graph".
>> So I went with that it can be any IRI.
>
>
> The wording you have applied is NOT similar to what I suggested - not 
> in any way. I don't believe that you understood the changes I was 
> requesting. If you had a question about this, you could have come back 
> to me before making the edit.

Any edit that I am making is primarily a proposal that be further 
changed or replaced. I am trying my best to accommodate the input that I 
receive, but you will understand that I need to also apply my own 
judgement about whether something makes sense or not. That's why I asked 
whether you can live with my edits. In cases where we still disagree we 
can ask the group. My tendency is already to accept suggestions even if 
I disagree, for the sole reason of making progress. Some things are just 
not worth fighting over, IMHO. In this particular case though, your 
proposed wording was not in accordance to the current design of SHACL, 
as I understand it.

>
> 1) I don't think that "any other IRI" is an answer.  If a random IRI 
> is included there I doubt if that would be useful. The bigger 
> question, though, is whether it would be valid SHACL. (And "valid 
> SHACL" is, at this moment in time, undefined.)
>
> The section says: "SHACL includes the following three pre-defined 
> severities, which are defined in the SHACL vocabulary as SHACL 
> instances of sh:Severity." Would a random IRI be a valid object of 
> sh:severity or must it be an instance of sh:Severity?

The rdfs:range of sh:severity is sh:Severity, and following usual RDFS 
practices this means that the system will assume that any IRI that it 
gets is an instance of sh:Severity, whether it has that type triple or not.

>
> 2) I actually have "which graph" questions about the entire validation 
> section because although it says "Each validation result must have 
> exactly one value for the property sh:severity." it doesn't say where 
> that value comes from -- it seems to come from thin air. However, 
> unless one is opting for the default "violation" the severity must be 
> coded in the shapes graph. I was adding a clarification about that to 
> the section with my suggested wording, and you didn't include that.

I did include that, see "in the shapes graph"

Constraints may specify their severity level in the <a>shapes graph</a> 
using the property <code>sh:severity</code>

and I also included a very long example that clarifies this.

>
> Again, I'd be happy to provide edits, but I'm not likely to put much 
> effort into edits since you appear to have the option to personally 
> reject proffered changes without discussion with me or with the group. 
> That leaves me with little recourse, and little possibility of having 
> an impact on SHACL. That's not a good state of affairs. I could 
> support a very different document that uses more precise language, but 
> what is here today is not acceptable to me. I don't know what the 
> solution is, but I cannot put in effort with no possibility of 
> impacting the final product.

You are completely misinterpreting the situation, see above.

Holger

Received on Thursday, 6 October 2016 23:54:23 UTC