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: Karen Coyle <kcoyle@kcoyle.net>
Date: Fri, 7 Oct 2016 09:03:06 -0700
To: public-data-shapes-wg@w3.org
Message-ID: <379cc647-3a9e-c71f-1bcb-c96d01d78790@kcoyle.net>

On 10/6/16 8:16 PM, Holger Knublauch wrote:
> 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.

Yes, I got distracted with other questions. I'll get back to that.


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

Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Friday, 7 October 2016 16:03:38 UTC

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