Re: shapes-ISSUE-130 (rdf dataset assumption): SHACL should not assume that the data graph is in an RDF dataset [SHACL Spec]

On 03/21/2016 04:09 PM, Holger Knublauch wrote:
> On 22/03/2016 5:39, Peter F. Patel-Schneider wrote:
>> My understanding is that access to the shapes graph during query execution
>> time is only needed at first glance to handle extension constructs like
>>     GRAPH $shapesGraph ....
>>
>> It can be convenient to use this construct in extension code so as to permit
>> the investigation of triples in the shapes graph.  This can be used, for
>> example, in the implementation of sh:classIn.  However, other implementation
>> methods are possible as you can attest to.
>>
>> There are then two questions:
>>
>> 1/ Is there some portion of the core of SHACL where access to the shapes graph
>> is needed at query execution time?  The answer to this is no.  Our two
>> implementations are partial evidence for this answer.
>>
>> 2/ Are there things that can be done with this access in the SPARQL extension
>> that cannot be done without it?  The answer to this is probably yes in some
>> sense but probably no in another.  Access to the shapes graph during query
>> execution allows the queries to pick up arbitrary information from the shapes
>> graph, thus the yes answer.  However, if there are only a few useful things do
>> be done on the shapes graph then each of them can probably be set up before
>> query execution, thus the no answer.
>>
>> For example, for constructs that have lists as arguments it is convenient to
>> just query the shapes graph to get the elements of the list.  However, it is
>> also possible at query preparation time to grab the elements of the list and
>> send them into the query.  This can be done in several ways, including via a
>> VALUES construct and via looping control in the query engine.
> 
> No, this is not possible,

It is indeed possible at query preparation time to grab the elements of a list
from the shapes graph and send them into the query.  This is what my
implementation of SHACL does.  It is also possible to do this from templates,
which is what my in-progress templated implementation of SHACL does.

> and I hope we don't reopen the longish $shapesGraph
> debate all over again. Extensions may write arbitrary queries against
> background data stored in the shapes graph, and there is no generic way of
> transforming any SPARQL query to avoid this. VALUES only allows you to
> iterate. 

I already said above that at query execution time it may be desirable for
queries to pick up (and process) arbitrary information from the shapes graph.

> In other cases you'd need FILTER IN and in others you'd need
> arbitrary Basic Graph Pattern matches against these external graphs. All these
> are very real world use cases that we encounter all the time. Proposal 4
> requires even more access to the shapes graph. (Even if it existed, formally
> defining such an algorithm would become a show-stopper for this WG, given that
> we already struggle with pre-binding).
> 
> ShapesGraph access is supposed to be optional for the Core vocab, and that was
> always the intention. Our definitions use $shapesGraph for convenience, but
> actual implementations can of course hard-code these queries instead, or in
> the worst case do outside loops against an endpoint.
> 
> Holger

peter

Received on Wednesday, 23 March 2016 23:04:44 UTC