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

On Sun, Jun 14, 2015 at 8:48 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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


Maybe I am wrong but I think you are aiming for corner cases. I asked if
there are use cases for access beyond core and you didn't say anything
besides a "nice-to-have feature" and that you "would be curious to observe
what our user base will produce with this".
On the other hand, I think everyone agrees that allowing arbitrary access
is problematic in immutable RDF datasets.
We had a similar case for global constraints where we could find a couple
of examples but decided to drop them for the same reason.

In case it wasn't clear, my suggested resolution refers *only* to the SPARQL
extension mechanism *beyond the core language*. What I suggest does not
refer to SHACL core or the spec.
Of course, I would be happy to re-consider if there is evidence that this
feature is indeed needed.

Also note that although SPARQL Endpoints are one case where access is
problematic, there can be many others when e.g. we apply SHACL in a
distributed processing system or a map-reduce step where we'll have the
 same limitations.

Best,
Dimitris


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


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