- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Sun, 2 Oct 2016 16:24:52 +0300
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a0EikSsnv8ooySAXkcrb2hrQ_pCKxRpaBgq_Oa3vaHp_Q@mail.gmail.com>
On Fri, Sep 30, 2016 at 6:40 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > Way down below... > > On 9/29/16 11:06 PM, Dimitris Kontokostas wrote: > >> >> >> On Fri, Sep 30, 2016 at 6:08 AM, Karen Coyle <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> wrote: >> >> >> >> 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. >> >> >> I reverted some of Holger's changes here wrt node->focus node >> >> Focus node is defined in the terminology as: "A node in the data graph >> that is validated against a shape is called a focus node." >> >> in the begining of section 4 (validation definitions) we want to say how >> to validate a node against a shape, as requested by the ShEx requirements >> meaning we take a node from the data graph and validate against a shape >> fromt he shapes graph, when the validation occus, that node becomes a >> focus node but the intent was to define the action prior to validation. >> > > Dimitris, I disagree here. I think that the node becomes the focus node > through the target/filter process, so at the point of validation > (comparison to the constraints) it is already the focus node. Otherwise, > you can't have a selected/targeted node to validate. I believe that you are > saying that constraints create the focus node. That doesn't seem to be how > it is described. > > As an example, the property constraint section says: > "Property constraints specify conditions that must be met with respect to > nodes that can be reached from the focus node either by directly following > a given property (specified using sh:predicate) or a given property path > (specified using sh:path)." > > So although you follow a property or path, you reach it from the focus > node. It doesn't say here that the property then becomes a new focus node. > If it is the intention that the focus node is modified as constraints are > applied, then that must be said in the document; that there is an initial > focus node, but that the focus changes as constraints are followed. > Hi Karen, I still think that these definition look at shapes & nodes at a little higher level. We have RDF nodes in the data graph that can be target nodes (when they are in the target of a shape) and *after* they pass the fliters of a shape they become "focus nodes" and the constraints are evaluated on them. However, I will not insist here, if you still think that we should replace node with focus node in the following definition let me know of you may also edit it directly "A node validates against a shape iff either it does not validate against some filter of the shape or none of the constraints in the shape produce a validation result or a failure for the node. Best, Dimtiris > kc > > >> >> >> >> >> >> >> 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 >> <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-u >> cr/#uc34-large-scale-dataset-validation >> <https://www.w3.org/TR/shacl-u >> cr/#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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> >> >> >> >> >> -- >> Dimitris Kontokostas >> Department of Computer Science, University of Leipzig & DBpedia >> Association >> Projects: http://dbpedia.org, http://rdfunit.aksw.org, >> http://aligned-project.eu >> Homepage: http://aksw.org/DimitrisKontokostas >> Research Group: AKSW/KILT http://aksw.org/Groups/KILT >> >> > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 > > -- Dimitris Kontokostas Department of Computer Science, University of Leipzig & DBpedia Association Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu Homepage: http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Sunday, 2 October 2016 13:25:49 UTC