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

On 6/12/15 3:52 PM, Dimitris Kontokostas wrote:
> If there is no other strong evidence that access is required I suggest 
> a resolution with more or less the following wording:
> The SPARQL based constraints cannot access the shapes graph. which is 
> inline with the issue description.
> The issue does not refer to the core language and we can create new 
> issues for core after e.g. we have a resolution for recursion. This 
> also leaves open how the spec is written.
> If we agree on this, implementers can optimize certain parts of core 
> to perform better since arbitrary access is not allowed.

Hi Dimitris,

I would always prefer a solution that makes everyone happy and have 
thought a lot about this topic, but the above proposal really doesn't 
work for me. Your proposal is like saying "I have this corner case here 
that may be slow, so nobody is allowed to have this feature". This 
reminds me of previous W3C groups that created languages that tried hard 
to avoid worst case complexity, throwing out features that would have 
been useful (and mostly harmless). With SHACL this attempt is pretty 
much hopeless: we already have the door wide open for all kinds of 
inefficiencies because we cannot control the kind of SPARQL queries that 
people are going to write. It's a bit like with a programming language 
such as Java. Yes, Java allows infinite loops and terribly inefficient 
code, yet it is the responsibility of the programmer to avoid such 
cases. Most programmers can make sensible use of this freedom.

Furthermore, I really don't understand what your concern is. In your 
example, I explained already that your validation scenario against the 
dbpedia SPARQL endpoint will not have any negative performance 
implications even if ?shapesGraph access remains legal for everyone else:
- Shapes that only use core constraints can already be in-lined into 
single SPARQL queries (except for recursion), regardless of how they are 
officially specified in our document. Engines are free to implement 
different algorithms (see below).
- If you are against access to the shapes graph then obviously you don't 
need this feature, so all your queries can already be directly executed 
against the endpoint alone.

Once you are in the land of SPARQL endpoints, you need to live with 
certain limitations anyway. For example you cannot talk about blank 
nodes anymore. You cannot use any SHACL extension function unless the 
endpoint is SHACL aware. There is a reason why we currently only support 
graphs and datasets, and no requirement mentions SPARQL endpoints.

> I also assume we will all try and make SHACL core as SPARQL Endpoint 
>  friendly as possible

Yes this sounds much better, but does not require deleting this feature 
for everyone else. In fact here is my proposal towards a compromise: We 
keep ?shapesGraph access for the standard dataset architecture but work 
on a separate document or appendix that provides the details on 
"Executing SHACL against SPARQL endpoints". This would include 
translation procedures for the core templates into single-query SPARQL 
strings (that Peter also advocated). For example, it would formalize how 
to turn a ClosedShape statement into a query using FILTER NOT IN ( ... 
list of properties ). It may also cover how to combine nested shapes 
into a single large query, including the logic to detect unsupported 
recursion cases. These instructions would lower the bar for engine 
implementers to be as SPARQL endpoint friendly as possible, yet keep the 
overall language consistent and elegant.

Regards
Holger

Received on Sunday, 14 June 2015 05:48:53 UTC