- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 20 Oct 2016 14:32:28 -0700
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
The google-doc that Dimitris and I are working from[1] has about 90 unresolved comments so far; many are from sections 3-4.2, which is what I am up to so far, since Dimitris has already worked on section 1-2.2. Some of them are language edits that are probably not controversial (although I would appreciate other eyes on those), so there are from 2-3 dozen that might be substantive. Generally these are places where it isn't just a matter of wording an/or it isn't clear what the meaning is. I want to give some examples here so that the group sees what kind of issues I feel need to be brought out in the draft. 1) 3.4.6 The property sh:detail may link a (parent)* result with one or more other (child) results that provide further details about the cause of the (parent) result. Depending on the capabilities of the SHACL processor, this may include violations of nested constraints** that have been evaluated via sh:shape. * Parent and child are not defined anywhere. It isn't clear what these refer to. All other uses of "parent/child" are in examples and refer to people. ** Nested constraints are not mentioned before this and are not defined. 2) 3.2 The data graph is expected to include all the ontology axioms related* to the data and especially all the rdfs:subClassOf triples in order for SHACL to correctly identify class targets and validate Core SHACL constraints.** * Not sure what ontology axioms are meant here, especially since SHACL does not make use of domains or ranges. AFAIK only class and sub/superclass are relevant to SHACL, but the way this says "especially" makes it sound like there are others. Are there others? Also "related to" is unclear. What makes an axiom "related to" the data? ** This makes it sound like SHACL core is only about class targets. Given that there are dozens of these, I would prefer not to write them up as issues. However, if that seems to be the best way, I will do so. However, as I have said, I would appreciate more eyes on the other aspect of the g-doc which is language edits. As I have said, differences in opinion have meant that my language edits to a fork of the document have not always been accepted, and I am therefore reluctant to go through the effort to edits that haven't been reviewed by other folks in the group. Thanks, kc [1]https://docs.google.com/document/d/1O24vnnZuTWQgi2-U_-lnY-IjV9EbRyxNtrYC3zq2pnM/edit#heading=h.6jvp5c2gxfub -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Thursday, 20 October 2016 21:32:58 UTC