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: Tue, 27 Sep 2016 14:38:45 +1000
To: public-rdf-shapes@w3.org
Message-ID: <f5d7494c-9972-7d19-1ae8-428b16f659ce@topquadrant.com>
On 27/09/2016 3:53, Peter F. Patel-Schneider wrote:
> But how is that sufficient to be able to implement sh:hasShape?
>
> It still appears to me that implementing sh:hasShape requires access to the
> shapes graph inside the SPARQL queries that implement SHACL constraint components.

The SPARQL queries of the SHACL constraint components do not in general 
require access to the shapes graph. This is merely the convention that 
we are using in the SPARQL definitions that are part of the spec. 
$shapesGraph access itself is optional in the spec. Therefore, there is 
also no need to pass the shapes graph IRI around using the sh:hasShape 
function. The shapes graph is implicitly known to the implementation, 
e.g. as a ThreadLocal variable in Java.

As the shapesGraph argument was causing more questions than benefits, I 
have taken it out from the spec for now:

https://github.com/w3c/data-shapes/commit/f16dc014a955496540f07f7d1cc342ce84794341

Thanks,
Holger


>
> peter
>
>
> On 09/25/2016 11:57 PM, Holger Knublauch wrote:
>> 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 Tuesday, 27 September 2016 04:39:18 UTC

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