W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: Quick Comments on https://www.w3.org/TR/2016/WD-shacl-20160814/

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
Message-ID: <4477c86c-0fe6-5933-79ff-3b9e81da56f3@gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC