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

Re: on access to the shapes graph in SHACL

From: Holger Knublauch <holger@topquadrant.com>
Date: Mon, 26 Sep 2016 16:38:16 +1000
To: public-rdf-shapes@w3.org
Message-ID: <cb4bd7a1-158f-78ab-007c-67f9e621aa58@topquadrant.com>
I have attached this as a comment to ISSUE-131, which is still open. I 
believe we can delete the shapesGraph argument from sh:hasShape and 
treat it as implicitly known to the engine. This should then resolve 
your concern here.

Holger


On 24/09/2016 3:12, Peter F. Patel-Schneider 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 Monday, 26 September 2016 06:38:56 UTC

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