Re: Shapes Constraint Language (SHACL) Working Draft of 2017-02-02

Shapes Constraint Language (SHACL)
W3C Working Draft 02 February 2017

SHACL-SPARQL processors MAY pre-bind the variable shapesGraph to provide
access to the shapes graph.

Otherwise, for each value node execute the SPARQL query specified by the
SPARQL-based constraint $sparql pre-binding the variables enumerated in
5.3.1 Pre-bound Variables in SPARQL Constraints ($this, $shapesGraph,
$currentShape).

$shapesGraph  Can be used to query the shapes graph as in GRAPH
$shapesGraph { ... }.

Not all SHACL-SPARQL processors need to support this variable.

The SPARQL query executions MUST use the same pre-bound variables as
enumerated in 5.3.1 Pre-bound Variables in SPARQL Constraints ($this,
$shapesGraph, $currentShape).

Two for optional, three for mandatory.


In Shapes Constraint Language (SHACL), W3C Editor's Draft 08 February 2017:

SHACL-SPARQL processors MAY pre-bind the variable shapesGraph to provide
access to the shapes graph.

Otherwise, for each value node execute the SPARQL query specified by the
SPARQL-based constraint $sparql pre-binding the variables this and, if
supported, shapesGraph and currentShape as described in 5.3.1 Pre-bound
Variables in SPARQL Constraints ($this, $shapesGraph, $currentShape).

$shapesGraph (Optional)  Can be used to query the shapes graph as in
GRAPH $shapesGraph { ... }

Not all SHACL-SPARQL processors need to support this variable.

The SPARQL query executions above MUST use the pre-bound variables this and,
if supported, shapesGraph and currentShape as described in 5.3.1 Pre-bound
Variables in SPARQL Constraints ($this, $shapesGraph, $currentShape).

Four for optional, one somewhat ambiguous.


So the problem definitely existed as of 2 Februrary 2017 and is not quite
yet eradicated.



Peter F. Patel-Schneider
Nuance Communications


On 02/08/2017 10:22 AM, Irene Polikoff wrote:
> I originally searched for *$shapesGraph* only. I now see the sentence you are referring to.
> 
> Irrespective, I believe the spec currently doesn’t have any tensions. It is consistently clear throughout that the support for this variable is optional and not a requirement for conformance.
> 
> Irene
> 
>> On Feb 8, 2017, at 12:25 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>> Both the current editors' draft and the current working draft still include
>>
>> SHACL-SPARQL processors MAY pre-bind the variable shapesGraph to provide
>> access to the shapes graph.
>>
>> Please try to carefully examine the document before replying.
>>
>> peter
>>
>>
>> On 02/07/2017 10:02 PM, Irene Polikoff wrote:
>>> Peter,
>>>
>>> The word MAY was not used to talk about this variable in the published draft.
>>> Having said this, I think the tension you are describing may have to do with
>>> the fact that section 5.3.1 talks about $shapesGraph and $currentShape as
>>> optional *if supported*, while sections 5.3 and 6.3 that refer to it said that
>>> these variables MUST be used.
>>>
>>> Please see modified language for sections 5.3 and 6.3 in the latest editor’s
>>> draft. Does this clarify the topic in your view?
>>>
>>> Regards,
>>>
>>> Irene Polikoff
>>>
>>>> On Feb 7, 2017, at 6:18 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com
>>>> <mailto:pfpschneider@gmail.com>> 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.”
>>>>
>>>>> RESPONSE: Please clarify the issue. What is unclear?
>>>>
>>>> The first sentence says that $-marked variables must be pre-bound or
>>>> substituted.  The second contracts that by using may.  The wording here has
>>>> changed somewhat, but it is still a tension between the two wordings.
>>>
>

Received on Wednesday, 8 February 2017 23:03:48 UTC