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

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

Received on Monday, 21 March 2016 23:09:53 UTC