- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 2 Oct 2016 08:54:57 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Arnaud - see below. Could this be a discussion at an upcoming meeting to see how others see filters and focus nodes? Should I make it an issue? kc On 10/2/16 6:24 AM, Dimitris Kontokostas wrote: > > > On Fri, Sep 30, 2016 at 6:40 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto: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> > <mailto: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. Dimitris, the part of the spec we are talking about is the validation section. If Filters take place as part of validation, then we should move them to the validation section. If validation takes place after the filters are applied, then at that point it is a focus node. My understanding (and I would like to hear from others) is that the entire process of validation takes place on focus nodes. > > 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. I'm also a bit concerned about that "iff" - while it is a commonly known shorthand for "if and only if" it is not English language and not universally known, so I think that "iff" should be written as "if and only if" when used in a sentence. If the section were in an abstract syntax then I think that "iff" would be appropriate. This section is not that formal. I do find it used in W3C documents when describing formal rules (see section 2.1 of the SWRL document [1]). kc [1] https://www.w3.org/Submission/SWRL/ > > 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> > > <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-ucr/#uc34-large-scale-dataset-validation > <https://www.w3.org/TR/shacl-ucr/#uc34-large-scale-dataset-validation> > > <https://www.w3.org/TR/shacl-ucr/#uc34-large-scale-dataset-validation > <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 <mailto:kcoyle@kcoyle.net> > <mailto: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> > <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 > <http://aksw.org/DimitrisKontokostas> > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > -- > 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
Received on Sunday, 2 October 2016 15:55:31 UTC