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

Re: $shapesGraph

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 23 Sep 2016 10:37:45 -0700
To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
Message-ID: <17ad3e6f-e72c-638d-647b-68207d1cc4c2@gmail.com>
See my recent more-general message on access to the shapes graph.


On 09/22/2016 10:17 PM, Holger Knublauch wrote:
> On 23/09/2016 11:36, Peter F. Patel-Schneider wrote:
>>> $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."
>>>     Comment (HK): The MAY is clarified in the following sentence (Access
>> to the shapes graph is not a requirement etc). I believe it would be
>> confusing to soften up the must in the first sentence because of this
>> exception.
>> It remains that there are two controlling wordings for how to handle
>> $shapesGraph, one with a must (which probably should be MUST) and one with
>> MAY.  These appear to be contradictory.
> The current wording of this has evolved to:
> 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 <#dfn-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.
> I can no longer find the original statements and I hope the issue has been
> addressed by the rewrite above.
> Holger
Received on Friday, 23 September 2016 17:38:17 UTC

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