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

On Jun 15, 2015 2:11 AM, "Holger Knublauch" <holger@topquadrant.com> wrote:
>
> On 6/14/15 10:56 PM, Dimitris Kontokostas wrote:
>>
>> 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".
>
>
> Why should the core language have a special status here? The constructs
of the core language are just one selection of common use cases - other
people will add their own. Currently the following core language constructs
are defined using ?shapesGraph: sh:allowedValues, sh:valueShape,
sh:NotConstraint, sh:AndConstraint, sh:OrConstraint, sh:XorConstraint,
sh:ClosedShape, plus the (not yet approved) qualified cardinality
constraints. Any recursive definition would require this. These are not
corner cases at all but just random examples of real-world scenarios.
>
> Here is another case, for named graph access in general. Assume you want
to validate that certain terms from a given query graph are also present as
SKOS concepts in some other graph. That SKOS named graph is not accessible
to the server running dbpedia. With the general SPARQL endpoint scenario
this is not implementable unless the endpoint can call out to external
named graphs. So endpoints are very limited already, but this limitation
shouldn't propagate into every use case.
>

This is just applying shacl in the union of two graphs. Not related to the
shacl graph or ?shapesGraph

>
>>
>> On the other hand, I think everyone agrees that allowing arbitrary
access is problematic in immutable RDF datasets.
>
>
> There are work-arounds for these cases, by wrapping the immutable
datasets with a virtual dataset. OTOH you didn't mention work-arounds for
the recursion issue yet,

(See later for details related to core.)
Sound and complete recursion is hard to optimize but a workaround would be
possible with precomputed prevalence and detection queries up to a fixed
level.

Regarding recursion, IMHO it might be convenient for some cases but there
are very few cases where it is actually needed and supporting it will not
be easy.

> nor SHACL functions nor blank node treatment.

I don't see anything special with blank nodes. OK Jenna has some additional
utility functions but there spec shouldn't rely on third party libraries.

> Instead you are suggesting a lowest-common-denominator approach in which
everyone can only use the features that the weakest link can also support.
This is IMHO a design mistake.
>
> We already have a separation between (ShEx) engines that don't want to
support SPARQL. In the worst case, we may also have modes that don't
support ?shapesGraph, while allowing others to use that feature.
>
>
>> 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.
>
>
> So did you say that ?shapesGraph can still be used inside of the core
language, i.e. the engine would have to support it anyway? This would be
better, but then why not also allow it in general? Queries that use
?shapesGraph are easy to spot and engines can fall back to the default
(e.g. by using Jena's own SPARQL engine). Nobody is forced to use
?shapesGraph.

That is my suggestion.
I don't like the general use because validation might break due to a
dependency in a shacl library that uses ?shapesGraph
People might use this for the wrong reasons so I would like to forbid this
if there is no actual need.
We can always reconsider later on the rec process or the next shacl version.

>
>
>>
>> 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.
>
>
> Even the distributed scenarios would require named graph support, e.g.
when someone has a GRAPH ?x statement in their SPARQL. So the main
differentiator seems to be immutability, i.e. the case in which it is
impossible to have the shapes graph as one named graph in the same dataset.

Graph support is not enforced to be supported while the shacl graph will be.

>
> What do you think about my proposal to specify the SPARQL generation
rules in a separate document or chapter? Wouldn't this be a compromise that
addresses all use cases?

That would definitely make the spec more complete - if the WG agrees on
this addition.

Dimitris
>
> Thanks
> Holger
>