> can you confirm that this is a bug ? Should I contruct a minimal
example ?
Can we agree on the test case?
I don't get he same numbers as you (data changing?) but do queries 1 and
3 represent the issue?
Reformatted for email:
==> Q1.rq <==
PREFIX :
<http://www.imagesnippets.com/imgtag/datasets/Michaels_Dataset/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT (count(*) AS ?c)
WHERE
{ GRAPH ?g
{ SERVICE <http://www.imagesnippets.com/sparql/datasets>
{ ?d rdfs:subClassOf :aidkjfsdf }
?s ?p ?d
}
==> Q3.rq <==
PREFIX :
<http://www.imagesnippets.com/imgtag/datasets/Michaels_Dataset/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?c
WHERE
{ SELECT (count(*) AS ?c)
WHERE
{ GRAPH ?g
{ SERVICE <http://www.imagesnippets.com/sparql/datasets>
{ ?d rdfs:subClassOf :aidkjfsdf }
Andy
>
Hello Andy,
On Wed, Jul 24, 2013 at 02:22:31PM +0100, Andy Seaborne wrote:
Line 8 sends the a request to the endpoint - GRAPH does not carry over
machines. Only the endpoint matters. So the SERVICE is on the default
graph (or union in this case).
SELECT *
{ ?d rdfs:subClassOf
<http://www.imagesnippets.com/imgtag/datasets/Michaels_Dataset/aidkjfsdf> }
?s ?p ?d
}
?s ?p ?d is all triples - if the rdfs:subClassOf has one hit, then there
are #triples in all named graphs.
But ?s ?p ?d is *outside* of the SERVICE in my query.
And however my query is evaluated - adding a "select ?c where {" and "}"
around it should not change the results - which is the case.
Regards,
Michael Brunnbauer
