- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 29 Sep 2016 20:08:11 -0700
- To: public-data-shapes-wg@w3.org
On 9/29/16 5:14 PM, Holger Knublauch wrote: > > > On 30/09/2016 10:06, Karen Coyle wrote: >> >> >> On 9/29/16 3:54 PM, Holger Knublauch wrote: >>> Hi Jose >>> >>> others may correct me, but my understanding is that all conformant SHACL >>> validation engines need to produce all the "mandatory" fields of the >>> results format. >> >> which are sh:focusNode and sh:severity - which is a bit awkward since >> the focus node (isn't that "target node" now?) doesn't tell you what >> constraints were evaluated. > > Yes, we need to clarify the mandatory fields (see your recent ticket). I would put them first in the section, followed by the "MAY" properties, rather than mixing them. Just a bit of readability assist. > > There is a subtle difference between focus node and target node: > - the focus node is the currently evaluated node > - the target node is a node specified as target by a shape > - target nodes becomes focus nodes for the duration of the validation > - but there are other ways for nodes to become focus nodes, e.g. via > sh:shape That makes sense, but it wasn't clear to me which was being referred to on reading that section. Oddly, the term "focus node" is not described in the section on validation (3.0-3.3), which however is where the focus node IS what is being validated. I suspect that at least some of the references to "node" there should instead be "focus node". E.g. in the first sentence: "The definitions for validating a data graph against a shapes graph as well as a *node* from the data graph against a shape from the shapes graph are provided below" Is that *node* a focus node? If so, it should say focus node there and in the remainder of that section. Then, 3.4.1 Focus node will make more sense. > >> >> >> They may decide to return less, but that should only be >>> an option. >>> >>> Our test cases should also include the full info, because engines that >>> only produce true or false can still use these test cases, while the >>> inverse is not the case. >> >> Since severity is mandatory, how will T/F work? > > Assuming that true means "no validations were found", then a test case > would pass if no results are produced, or at least no results with > severity violation. 3.4 says "The validation report is the result of the validation process and includes a set of zero or more validation results." Can you give an example of a validation report without validation results? If it is the absence of a validation result, I have trouble with it being called a "set", which in my mind has an identity, even when empty. Thanks, kc > > Holger > > >> >> kc >> >>> >>> Holger >>> >>> >>> On 29/09/2016 19:59, RDF Data Shapes Working Group Issue Tracker wrote: >>>> shapes-ISSUE-181: SHACL conformance for partial validation reports >>>> [SHACL Spec] >>>> >>>> http://www.w3.org/2014/data-shapes/track/issues/181 >>>> >>>> Raised by: Jose Emilio Labra Gayo >>>> On product: SHACL Spec >>>> >>>> When preparing the test-suite, it is not clear to me if we have to >>>> declare/check all the validation reports that must be returned by a >>>> SHACL processor or just a true/false. >>>> >>>> The spec contains the following phrase: >>>> >>>> "The validation process returns a validation report containing all >>>> validation results. For simpler validation scenarios, SHACL processors >>>> SHOULD provide an additional validation interface that returns only >>>> true for valid or false for invalid." >>>> >>>> A SHACL processor that wants to handle use case 3.31 >>>> (https://www.w3.org/TR/shacl-ucr/#uc34-large-scale-dataset-validation) >>>> about validating very large datasets may decide to return just the >>>> first violation it finds, instead of continue processing/generating >>>> all the possible violations. >>>> >>>> Is that SHACL processor conformant with the spec? In that case, when >>>> defining the test-suite, is it enough if we just declare true/false as >>>> the possible result of SHACL validation? Or if a SHACL processor >>>> returns just the first violation report that it finds? >>>> >>>> In any case, I think the spec should be more clear about when a SHACL >>>> processor is conformant or not if it doesn't return all the violation >>>> reports and just returns the first one or signals that there was an >>>> error. >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 30 September 2016 03:08:42 UTC