- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 7 Oct 2016 09:03:06 -0700
- To: public-data-shapes-wg@w3.org
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. kc > > 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 >> > > > -- 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