Re: on access to the shapes graph in SHACL

The idea is that the SHACL engine would already have the "pointer" to 
the shapes graph, and will reuse that to pre-bind the $shapesGraph 
variable if it needs to. In other words, the parameter would be implicit.

Holger


On 26/09/2016 16:49, Peter F. Patel-Schneider wrote:
> I don't think that this follows unless sh:hasShape can be fully implemented
> when there is no access to the shapes graph.
>
> peter
>
>
> On 09/25/2016 11:38 PM, Holger Knublauch wrote:
>> 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:58:01 UTC