- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 22 Sep 2016 16:35:22 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
That's a pointer to a mutable page, which is not suitable as a record of a response to my comments. Please arrange for a non-mutable record. Peter F. Patel-Schneider Nuance Communications On 09/22/2016 04:29 PM, Holger Knublauch wrote: > Hi Peter, > > many thanks for your input. We have tried to address your issues as outlined > here: > > https://www.w3.org/2014/data-shapes/wiki/Public_Comments#Peter.27s_Email_2016-08-16 > > > With a couple of items we were not sure what to do, and would appreciate > clarification. > > The major unhandled issue relates to the SPARQL EXISTS / pre-binding topic, on > which we hope to receive some input from the corresponding CG that you are > also member of. > > Regards > Holger > > > On 16/08/2016 8:03, Peter F. Patel-Schneider wrote: >> Here are a few of the problems with the current public working draft I found >> during a quick scan of it. >> >> * pre-binding >> >> SPARQL does not evaluate variables that occur in basic graph patterns. This >> means that the definition of pre-binding has unusual behaviour. For >> example, the normative SPARQL definition of sh:class will return validation >> results for every pair of nodes in the graph such that there is an >> rdf:type/rdfs:subClass* path from the first to the second. >> >> This problem affects many parts of the definition of SHACL. It means that >> the normative definition of many SHACL constructs is counter to intuitions. >> This problem is not ameliorated by the caution box in Appendix B. >> >> * syntax of SPARQL variables >> >> SPARQL treats $ and ? as equivalent so $PATH and ?PATH both refer to the >> PATH variable. SHACL uses $ as a special marker and includes $ and ? as >> part of the variable. >> >> Would ?PATH be substituted as $PATH is? If a SPARQL query for a SHACL >> constraint only used ?this would the variable this be pre-bound? >> >> * pre-binding optional? >> >> "SPARQL variables using the $ marker represent external values that must be >> pre-bound or substituted in the SPARQL query before execution." >> "When SPARQL constraints are executed, the validation engine should pre-bind >> values for these variables." >> Are some $-marked variables not necessarily pre-bound, counter to the >> earlier requirement? >> >> * $PATH vs other $-prefixed variables >> >> The variable PATH is treated specially in SHACL. However, the general >> description of $ does not specially call out PATH: >> "SPARQL variables using the $ marker represent external values that must be >> pre-bound or substituted in the SPARQL query before execution." >> >> * $value >> >> $value is used in many ASK queries. However the definition of ASK >> validators does not appear to pre-bind value. >> >> * aggregation >> >> The prohibition "Furthermore, any query that uses the variable $this in an >> aggregation is invalid." is vague. It appears to disallow the use of $this >> in any part of the SPARQL 1.1 aggregation machinery, as the pointer in the >> sentence is to Section 11 of the SPARQL specification. This would rule out >> all of the examples of aggregation in the SHACL document. >> >> * ASK validators syntax >> >> The syntax for ASK queries in SPARQL 1.1 is >> "ASK" DatasetClause* WhereClause SolutionModifier >> The syntax for WhereClause is >> 'WHERE'? GroupGraphPattern >> The syntax for EXISTS constructs SPARQL 1.1 is >> 'EXISTS' GroupGraphPattern >> Stripping the ASK from the beginning of an ASK query does not generally end >> up with a GroupGraphPattern that can be used as the argument for EXISTS. >> >> It appears that the values of sh:ask are never used as ASK queries by SHACL >> processors. Why then are these of the form of ASK queries? >> >> * different levels of SHACL implementation >> >> There are several different kinds of SHACL implementations that are hinted >> at in the document. >> >> "SHACL implementations may, but are not required to, support entailment >> regimes." >> "Access to the shapes graph is not a requirement for supporting the SHACL >> Core language." >> "This sections [sic] defines the built-in SHACL constraint components that >> MUST be supported by all SHACL validation engines." >> "Not all SHACL validation engines need to support this variable." >> "The same support policies as for $shapesGraph apply for this variable." >> "SPARQL engines with full SHACL support can install a new SPARQL function >> based on the SPARQL 1.1 Extensible Value Testing mechanism." >> "SHACL validation engines are not required to support any entailment regimes." >> "SHACL implementations with full support of the SHACL SPARQL extension >> mechanism must implement a function sh:hasShape, ...." >> "A SHACL validation engine MUST implement all constructs in the Core of SHACL >> (Sections 2, 3, 4). A SHACL engine MAY not implement the other parts of >> SHACL." >> "Implementations that cover only the the SHACL Core features are not >> required to implement these mechanisms or the sh:hasShape function." >> "SHACL validation engines MAY pre-bind the variable $shapesGraph to provide >> access to the shapes graph." >> "A SHACL validation engine MAY use such suggestions to determine which shapes >> graph to use for validating a data graph." >> "A SHACL validation engine MAY take this information into account to >> determine which shapes graph to use for validating a data graph that uses >> that ontology or vocabulary." >> >> There needs to be a section that explicitly defines the different levels of >> implementation. >> >> * order of processing for filters >> >> The discussion of how filters are processed appears to be contradictory. >> First there is: >> "SHACL validation engines MAY alter the order of the depicted steps as long >> as the returned validation results are correct." >> Later there is: >> "Filter shapes MUST be evaluated before validating the associated shapes or >> constraints." >> >> * $shapesGraph >> >> The status of $shapesGraph is unclear: >> "SPARQL variables using the $ marker represent external values that must be >> pre-bound or substituted in the SPARQL query before execution." >> "SHACL validation engines MAY pre-bind the variable $shapesGraph to provide >> access to the shapes graph." >> >> * circular filters >> >> What happens if a shape is one of its own filters? >> >> * EXISTS and blank nodes >> >> The definition of ASK binds the value variable and then uses it inside an >> EXISTS. The definition of SPARQL provides a counter-intuitive result if >> this variable is bound to a blank node, resulting in, for example, a >> sh:class constraint with class ex:C returning no violation for _:d in any >> data graph containing the triple >> ex:c rdf:type ex:C . >> >> * union operations on data graphs and shapes graphs >> >> It is unclear just what the data graph and the shapes graph are. There is >> wording that both of these cannot be changed. However, there is also >> wording that various kinds of union operations are to be performed on shapes >> and data graphs. >> >> >> * It is unclear what is meant by: "The variable $targetNode is assumed to >> be pre-bound to the given value of sh:targetNode." Is this something that >> SHACL implementations have to do? There are several occurences of this >> kind of wording. >> >> * MAY is used in 1.5 but defined in 1.6 >> >> * "A SHACL engine MAY not implement the other parts of SHACL." reads as if >> no SHACL engine is allowed to implement any non-core part of SHACL. >> >> * "The data graph SHOULD include all the ontology axioms related to the data >> and especially all the rdfs:subClassOf triples in order for SHACL to >> correctly identify class targets and validate Core SHACL constraints." >> Data graphs are just graphs. How thus can SHOULD be applied to them? >> >> * "A SHACL validation engine MAY use such suggestions to determine which >> shapes graph to use for validating a data graph." Can this be done even >> when an explicit shapes graph is provided to the engine? >> >> * "The same mechanism applies for ontologies or vocabularies included in the >> shapes graph. The ontology or the vocabulary IRI can point to one or more >> shapes graphs with the predicate sh:shapesGraph. A SHACL validation engine >> MAY take this information into account to determine which shapes graph to >> use for validating a data graph that uses that ontology or vocabulary." >> If there already is a shapes graph in play, why is there any need for a >> different shapes graph to be used? >> >> * "a deep copy of sh:path as its sh:path" What is "deep copy" in this >> context? >> >> * "A filter is a shape in a shapes graph that can be used to limit the nodes >> that are validated against a given constraint or shape." Are there some >> filters that cannot be used in this way? Which ones? >> >> * "The following table enumerates variables that have special meaning in >> SPARQL constraints. When SPARQL constraints are executed, the validation >> engine should pre-bind values for these variables." However, many other >> variables also need to be pre-bound, such as the variables corresponding >> to parameters. >> > >
Received on Thursday, 22 September 2016 23:35:57 UTC