- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 5 Oct 2016 08:56:53 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Thanks, Dimitris. Here are some comments: "typically a <a>SHACL instance</a> of <code>sh:Shape</code>" - why "typically"? In a standard, I think it has to be either yes or no. Even if it is optional, "typically" is not appropriate language. "A shape provides a collection of <a>targets</a>, <a>filters</a>, <a>constraints</a> and <a>parameters</a> of <a>constraint components</a>" What is a collection? Also, does every shape have targets and filters and constraints? If not, which are optional? Can you have a shape with none of them? Can any be repeatable? "Focus node: A <a>node</a> in the <a>data graph</a> that is validated against a <a>shape</a> is called a <dfn data-lt="focus node|focus nodes">focus node</dfn>." This has the "validated" problem - Validation needs to be defined, especially because of the English language root "valid" which means something that is "true". I suggest taking a definition from the XML schema document.[1] Also note that the entry in the terminology that includes validation is 1) not a definition of any of the terms and 2) each term should be defined separately. By this I mean: "Data Graph, Shapes Graph, Validation, Report, Result, Violation, Failure SHACL defines what it means for an RDF graph, referred to as the data graph, to validate against an RDF graph containing shapes, referred to as the shapes graph. The result of validation is a validation report including validation results such as informational results, warnings and violations. Validation may also result in a failure, which is reported by a SHACL processor to indicate that a request could not be handled. Failures are not represented as part of the validation report, but through implementation-specific channels. Validation of a shapes graph against a data graph involves validating each shape in the shapes graph against the data graph. A node in a data graph is said to validate against a shape if validation of that node against the shape neither produces any validation results nor results in a failure." Not one term is defined there. [1] https://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#concepts-schemaConstraints On 10/4/16 8:20 PM, Dimitris Kontokostas wrote: > Hi Karen, > > This is a work in progress but tries to define focus nodes better > https://github.com/w3c/data-shapes/commit/095364dd05d103ca117eb9570d3b48ddf46a580d > > regarding 2.1 > maybe this also needs better wording but here's the explanation > > ex:shapeA > sh:targetClass ex:Foo. > sh:property [ > sh:predicate ex:foo ; > sh:shape ex:shapeB; > ]. > > > ex:shapeB > sh:targetClass ex:Bar. > sh:property [] > ... > > shapeB has 2 roles in this shapes graph > 1) validate all instances of ex:Bar against ex:shapeB > 2) serve as a nested shape for ex:shapeA > in the latter (only) the focus nodes are provided by ex:shapeA and the > target of ex:shapeB is ignored "nested shape" is not defined in the document. Nor do I see where it says that the target of ex:shapeB is ignored. I see it in this example, but I don't see it in the document. I may have missed it. However, I believe this may alter the definition of shape, since it means that there are two kinds of shapes - primary and nested, and there are different rules applied to them. > > we also write in the spec (2.1) : > While targets define the starting points of the validation process, > some shapes may validate > - less focus nodes when a shapes defines filters, or > - additional focus nodes against different shapes, for example when > referenced via sh:shape and sh:or. This is what I was asking about - there is a "starting point" but the focus node may change when constraints are applied - that's what this says. But "for example" isn't enough. It needs to be defined unambiguously exactly what happens, and it must list all of the properties that can modify a focus node. Reading the above, though, I have the impression that you are speaking of targets, not focus nodes. It isn't a focus node until all of the criteria that can modify the target are applied and it is "validated". I apologize, Dimitris, because this is all coming down on you, but quite honestly this document does not read as a specification for a standard. I agree with Peter that the language is way too loose, and that too many conditions are left undefined. I still find that the document is far from what I would expect as a standards document. As always, I am willing to put more work into it doing direct editing, but it is nearly impossible at this point to make all of the comments in email because they are too many. kc > > let me know if this helps and if possible, which parts are still unclear > > Thanks > Dimitris > > > On Tue, Oct 4, 2016 at 6:03 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > Here's what I see as the offending sentence, which is also one that > Peter cited: > > "The focus nodes may also be determined as > part of the validation of constraints that include references to shapes > using properties such as sh:shape and sh:or." > > That is in the first paragraph of 2.0. > > See: > > (2.1) "Targets are ignored when a shape is processed as a nested > shape in shape-based constraint components (i.e. sh:shape), logical > constraint components (i.e. sh:or), filter shapes (sh:filterShape) > or, for SHACL Full, in the evaluation of the sh:hasShape SPARQL > function as defined in appendix A." > > I'm not sure what "targets are ignored" actually means, unless it > means that the entire data graph is the target. If you ignore a > target, then what are you paying attention to? Or is the meaning > that sh:shape and sh:or extend the target? Where you do first > connect with the data graph if there is no target? > > kc > > > On 10/3/16 8:16 AM, Karen Coyle wrote: > > I still find the definition of focus node circular. The focus > node is > defined as (in terminology): > > "A node in the data graph that is validated against a shape is > called a > focus node." > > This essentially says: if it is validated against a shape, then > it is a > focus node. > > But there is a focus node constraint that defines constraints on the > focus node. So now there is a constraint defined on a focus node > that > (as per the terminology) cannot exist until validation takes place. > > Also note that in the validation section, the only mention of focus > nodes is in the validation report. There is no description of > using (or > creating) focus nodes in validation. Since the Targets section > does not > define focus nodes, only targets, they have not been defined > anywhere in > sections 2 or 3. > > kc > > On 10/2/16 11:35 AM, Dimitris Kontokostas wrote: > > Hi Karen, > > On Sun, Oct 2, 2016 at 6:54 PM, Karen Coyle > <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote: > > > 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. > > > Section 2 describes shapes, targets, filters and > constraints, then > section 3 describes validation as well as the data graph, > shapes graph > and validation results. > All constructs described in section 2 are referenced in the > validation > definition but any feedback to restructure these sections is > more than > welcome. > > Based on my understanding, > filters are of course part of the validation process but the > term focus > node is used when the nodes reach the constraints of the shape. > As I said, I do not have a strong opinion on this and would > be happy to > discuss this further during the next call or hear what > others have to say > > 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]). > > > I replaced iff according to your suggestion. > > Thanks, > Dimitris > > -- > 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> > <http://aksw.org/DimitrisKontokostas > <http://aksw.org/DimitrisKontokostas>> > Research Group: AKSW/KILT http://aksw.org/Groups/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 Wednesday, 5 October 2016 15:57:25 UTC