- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 5 Sep 2016 08:13:12 -0700
- To: public-data-shapes-wg@w3.org
ISSUE-71 is about validation that takes place within the SHACL validation workflow. If it were not, then it wouldn't be an issue and a requirement. kc On 9/4/16 3:13 PM, Holger Knublauch wrote: > I cannot follow this train of thought. According to that logic, the > SHACL network prototol ISSUE-71 (that you seem to want) cannot be part > of SHACL either. We should standardize what is *useful*, not because of > some artificial boundaries. Rules are the most popular feature in SPIN, > and here is an opportunity to make SHACL more useful at low cost. Rules > are in the same category as other forms of entailment, which are > officially part of SHACL, see sh:entailment. > > Holger > > > On 5/09/2016 3:42, Karen Coyle wrote: >> If it happens BEFORE the invocation of a SHACL graph/data graph >> comparison, then it cannot be part of the SHACL standard. After all, >> we haven't included the creation of explicit rdf:type statements >> within SHACL. >> >> kc >> >> On 8/31/16 11:59 PM, Holger Knublauch wrote: >>> From the recent meeting minutes I can see that Ted remarked [1] >>> >>> long ago we decided that SHACL engines would be fed a graph which it >>> would validate, and that SHACL engines would not change that graph >>> before validation ... but this reverses that and re-opens many past >>> decisions >>> >>> I agree with the previous decision and notice that the wording in the >>> proposed section was not clear. I have changed the wiki page to clarify >>> that the execution of rules happens *before* the data graph is produced, >>> i.e. the data graph is the result of applying rules on some other >>> "input" graph. Rules will not modify the data graph, but operate in the >>> same way that other entailments are implemented. >>> >>> Holger >>> >>> [1] https://www.w3.org/2016/08/25-shapes-minutes.html#item04 >>> >>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 5 September 2016 15:13:42 UTC