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 <holger@topquadrant.com>
wrote:

> 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.

Dimitris


>
>
> Holger
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://http://aligned-project.eu,
http://rdfunit.aksw.org
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: http://aksw.org