Re: on access to the shapes graph in SHACL

Not really.

It is still the case that SHACL Full processors are supposed have to option of
not implementing access to the shapes graph.  However, they do need to fully
implement sh:hasShape, which does need access to the shapes graph.  This does
not make sense.

peter




On 09/24/2016 06:54 AM, Dimitris Kontokostas wrote:
> Hi Peter,
> 
> See my reply on "different levels of SHACL" I think that resolves this issue
> as well
> 
> Thanks for your feedback,
> Dimitris
> 
> On Friday, September 23, 2016, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     Following up one of the recent responses to my comments on Shapes Constraint
>     Language (SHACL) lead me to look at how access to the shapes graph works in
>     Shapes Constraint Language (SHACL), W3C Editor's Draft 22 September 2016.
> 
> 
>     The initial discussion of access to the shapes graph is in Section 1.6:
> 
>     "SHACL Full processors MAY pre-bind the variable shapesGraph to provide
>     access to the shapes graph. Access to the shapes graph is not a requirement
>     for supporting the SHACL Core language. The variable shapesGraph can also be
>     used in user-defined SPARQL constraints and SPARQL-based constraint
>     components. However, such constraints may not be interoperable across
>     different SHACL Full processors or not applicable to remote RDF datasets."
> 
>     Given the first "MAY" here, it appears that access to the shapes graph is
>     neither a requirement for supporting the SHACL Full language.  This puts
>     access to the shapes graph in a kind of SHACL Fuller.
> 
>     The next discusion is in Section 5.3:
> 
>     "$shapesGraph   Can be used to query the shapes graph as in GRAPH
>     $shapesGraph { ... }. If the shapes graph is a named graph in the same
>     dataset as the data graph then it is the IRI of the shapes graph in the
>     dataset. Not all SHACL Full processors need to support this
>     variable. Processors that do not support $shapesGraph MUST report a failure
>     if they encounter a query that references this variable. Use of GRAPH
>     $shapesGraph { ... } should be handled with extreme caution. It may result
>     in constraints that are not interoperable across different SHACL Full
>     processors and that may not run on remote RDF datasets."
> 
>     Again, access to the shapes graph is in SHACL Fuller.
> 
> 
>     The final discussion is in Appendx A:
> 
>     "SHACL Full processors must implement the function sh:hasShape, which takes
>     the following parameters:
>     Parameter       Value Type      Summary
>     focusNode       rdfs:Resource   The focus node to validate.
>     shape           rdfs:Resource   The shape to validate the focus node against.
>     shapesGraph     rdfs:Resource   The IRI of the current shapes graph."
>     An example call of this function is
>       BIND (sh:hasShape(ex:JohnDoe, ex:PersonShape, $shapesGraph) AS ?hasShape)
>     None of the parameters can be unbound."
> 
>     But now it appears that access to the shapes graph is a required part of
>     SHACL Full processing, contradicting to the previous discussion.
> 
> 
>     Peter F. Patel-Schneider
>     Nuance Communications
> 
>

Received on Saturday, 24 September 2016 22:22:31 UTC