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

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

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 7 Oct 2016 13:16:42 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <2c8b9a59-59f0-86b2-dedc-23329ca75665@topquadrant.com>
It occurred to me that in order to understand why any IRI is allowed for 
sh:severity it would be helpful to know that SHACL enforces no "meaning" 
whatsoever into the specific values of sh:severity. The WG recently had 
a resolution in this respect, and a consequence is that it can really be 
anything.

I have made further edits to 3.4.8 and 3.4.9 to clarify this, and also 
to crosslink from 3.4.8 to 3.4.9 to explain where the actual values are 
coming from.

A potential issue remains that we are using the same property name 
sh:severity both in the shapes and the results graphs. You had indicated 
you wanted to raise a formal issue on that, but I haven't seen it yet.

HTH
Holger


On 7/10/2016 9:53, Holger Knublauch wrote:
> 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 Friday, 7 October 2016 03:17:18 UTC

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