Re: on access to the shapes graph in SHACL

On 09/26/2016 09:38 PM, Holger Knublauch wrote:
> 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

Even if the explicit shape graph argument to sh:hasShape is removed, it is not
obvious to me that sh:hasShape can be implemented without access to the shapes
graph (or at least something that encodes all the information from the shapes
graph).  It's also might be possible that sh:hasShape can be implemented
without access to this information.

However, unless it can be shown that the sh:hasShape can be indeed shown to be
implementable without access to the shapes graph then it doesn't seem to me to
make sense to make $shapesGraph support optional.

Peter F. Patel-Schneider
Nuance Communications

Received on Tuesday, 27 September 2016 05:24:33 UTC