Re: Intended behavior for invalid IRI in "GRAPH <iri> { } block

good afternoon;

On 15 Nov 2013, at 5:27 PM, Thomas Visel wrote:

> Andy,
>  
> Section 13.3.2 of the SPARQL spec deals with Restricting by Graph IRI.  There is a question of intended behavior when the specified IRI is neither among the FROM NAMED statements nor supplied by the Http protocol. 
>  
> One could presume from the example and text of Section 13.3.2 that nothing gets returned, to put it simply.  Another option is that rather than returning an empty set, the handler errors of because of an improperly framed query.  The answer has implications for query optimization.

what should imputed correctness imply about performance optimization? 

in most cases, we favor the principle, that an implementation should neither establish any restriction nor standardize any extension which the specification does not require, as to be conservative promotes interoperability. there are very limited cases which have persuaded us otherwise.

in one, we reject queries which employ unknown terms from standard schema. over the period we have been in service, any such failures are followed immediately by a corrected request.

in another, we had a hard requirement, that any referenced variable, that is those in filter, bind, or select expressions, must be bound, but we have been convinced to moderate this. there were well-argued cases where the mechanism was used deliberately to control execution of parametrized queries. whereby, while parameterized execution is not standard, it is well enough established in the state-of-the-art, that we were convinced to allow this.

graph designators which do not appear in a declared dataset, on the other hand, should be treated the same as graph designators which do not appear in the default dataset established by the store when none has been declared. this treatment should be same as that for designators which are know to not appear in a store at all. which, to return to the distinction between proscription and optimization, could be to optimize the execution of such queries, but independent of any argument to reject them.

best regards, from berlin,

>  
> The issue is more clearly seen in the example (following) from Section 13.3.3, wherein the results of a GRAPH restricted by <IRI> are used as the basis for a subsequent GRAPH restricted by a variable.
>  
> PREFIX  data:  <http://example.org/foaf/>
> PREFIX  foaf:  <http://xmlns.com/foaf/0.1/>
> PREFIX  rdfs:  <http://www.w3.org/2000/01/rdf-schema#>
>  
> SELECT ?mbox ?nick ?ppd
> FROM NAMED <http://example.org/foaf/aliceFoaf>
> FROM NAMED <http://example.org/foaf/bobFoaf>
> WHERE
> {
>   GRAPH data:aliceFoaf_baddie
>   {
>     ?alice foaf:mbox <mailto:alice@work.example> ;
>            foaf:knows ?whom .
>     ?whom  foaf:mbox ?mbox ;
>            rdfs:seeAlso ?ppd .
>     ?ppd  a foaf:PersonalProfileDocument .
>   } .
>   GRAPH ?ppd
>   {
>       ?w foaf:mbox ?mbox ;
>          foaf:nick ?nick
>   }
> }
>  
> Reframed, the question is this:  When the <IRI> is correctly formed yet not included in a FROM NAMED (or Http protocol), ought the behavior be to error off from an improper query or simply return the empty set?  (Obviously, under some engine implementations it makes no difference.)
>  
> Regards,
>  
> Thomas Visel
>  
>   
> <image001.png>
> Thomas A. Visel, Senior Translation Engineer
> Office:  512-651-5834
> Email: tviselalgebraixdata.com
> www.algebraixdata.com
>  



---
james anderson | james@dydra.com | http://dydra.com