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

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

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

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.

Holger

Received on Thursday, 11 June 2015 20:19:17 UTC