Re: resolving ISSUE-47: Can SPARQL-based constraints access the shape graph, and how?

On Thu, Jun 11, 2015 at 11:18 PM, Holger Knublauch <>

> On 6/12/15 5:51 AM, Dimitris Kontokostas wrote:
>> Summing up from the meeting, the whole core language can be implemented
>> without access to the constraints graph.
> Could you clarify or give examples? I believe this requires a substantial
> change from a template-based generic approach to a solution in which these
> core templates require a different, hard-coded mechanism to produce SPARQL
> queries. I would find the latter very ugly and it adds to the
> implementation burden.

Implementers who do not want to support SPARQL Endpoints can do
optimizations like the ones in the current spec.

> One of the very strengths of RDF and OWL is that people can use the same
> mechanism to query data and ontology, and here we are simply allowing that
> same principle.

I agree and this is the reason we define SHACL in RDF. However, I don't
think ontologies are required to exist / queried together with data.

>  Some parts of the spec would indeed be simpler with access to the
>> constraints graph but I don't see this alone as a reason to require access.
>> I suggest we gather all the use cases where access is needed beyond the
>> core language and evaluate them.
> One case is recursion (e.g. sh:valueShape). How could this be implemented
> without a function such as sh:hasShape, which takes a shape as a parameter?

There is no resolution for recursion yet.
Besides this, are there any other use cases beyond the core language?

> As Peter stated, if we don't allow access to the shapes graph, then a lot
> of things in the current design would need to change. I think we should
> take a hard look at the counter arguments before making such a change. I
> accept there may be performance implications for scenarios such as remote
> SPARQL execution against large databases, but in those cases there are
> work-arounds such as generating optimized SPARQL queries. Many engines may
> decide to implement optimizations for the core language anyway. But since
> these are performance optimizations only, I don't think they should limit
> what the general spec allows.

Querying big SPARQL endpoints is already a slow process and with this
approach SHACL makes it even slower.
We have a few SPARQL vendors in the WG, I am wondering about their opinion
on this.


> Holger

Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects:, http://,
Research Group:

Received on Thursday, 11 June 2015 22:15:33 UTC