Re: on access to the shapes graph in SHACL

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:50:00 UTC