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:[email protected]] Sent: Friday, November 15, 2013 11:09 AM To: Thomas Visel Cc: [email protected] 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 <[email protected]<mailto:[email protected]>> 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:[email protected]> ; 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:[email protected]> www.algebraixdata.com<https://mail.algebraixdata.com/owa/redir.aspx?C=2d0be5b032904ed29d54d21121723791&URL=http%3a%2f%2fwww.algebraixdata.com%2f>
