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

Jeremy,
Thanks for your quick response.  I believe the question was misinterpreted, though, or perhaps poorly framed on my part.  This is not a question of data intersections, but of error response.

When using "GRAPH <iri>" restrictions, that <iri> must be given in a "FROM NAMED" statement.  The question asked was of behavior when the <iri> was not given in a FROM NAMED.  What behavior was intended by the spec in that case.  Was it the intention that the GRAPH simply return an empty set, or should it return an error to the Http endpoint?  I do not find this addressed in the spec anywhere, nor is it in the WG archives.

My regards,

Thomas Visel

From: Jeremy J Carroll [mailto:jjc@syapse.com]
Sent: Friday, November 15, 2013 11:09 AM
To: Thomas Visel
Cc: public-sparql-dev@w3c.org
Subject: Re: Intended behavior for invalid IRI in "GRAPH <iri> { } block

It seems to me that this is a case of the standard being clear and there being a compelling use case which is better addressed by other behavior.

It is certainly possible to build an application that *uses* the standard behavior to do logic with the graph names, and hence the standard is not demonstrably wrong, simply arguably less useful than it might have been

e.g. I believe one way of doing an intersection between sets of names of graphs in your triple store is with nested subselects using from named.


select ?g
FROM NAMED <g1>
FROM NAMED <g3>
{
   { SELECT ?g
     FROM NAMED <g2>
     FROM NAMED <g3>
    {  GRAPH ?g {} }
  }
}

should return <g3> whereas with (the obvious extension of) your proposal it should give an error with <g2>


Jeremy J Carroll
Principal Architect
Syapse, Inc.



On Nov 15, 2013, at 8:27 AM, Thomas Visel <tvisel@algebraixdata.com<mailto:tvisel@algebraixdata.com>> 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.

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#<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<mailto:rbenci@algebraixdata.com>
www.algebraixdata.com<https://mail.algebraixdata.com/owa/redir.aspx?C=2d0be5b032904ed29d54d21121723791&URL=http%3a%2f%2fwww.algebraixdata.com%2f>