Re: Possible Bug Roundtripping SPARQL to an SSE and back

[Andy Seaborne]

On 04/06/15 12:28, Rob Vesse wrote:

Rick

Yes this does look like a bug

Agreed.  If the DISTINCT is being pulled up, it's wrong.
LIMIT is missing as well.

A slight but though ...

Where does "?tripod_count_var" come from?

The algebra shown names a variable not in the query.

The input query has algebra:

(project (?count)
  (extend ((?count ?.0))
    (group () ((?.0 (count)))
      (slice _ 1
        (distinct
          (project (?uri ?graph)
            (graph ?graph
              (bgp (triple ?uri ?p ?o)))))))))

        Andy

Please bear in mind however that conversion to algebra does NOT guarantee
to round trip because some parts of a query do not end up in the algebra
and so OpAsQuery has simply no way to reconstruct the exact original query

For example:

SELECT * {
   SELECT ?x { ?x a ?type }
}

Would round trip back to just:

SELECT ?x { ?x a ?type }


There are also other cases where things could move around slightly, for
example a BIND is potentially indistinguishable from a SELECT expression
depending on the structure of the query.

I have filed this as JENA-954 -
https://issues.apache.org/jira/browse/JENA-954

Thanks for reporting this,

Rob

On 04/06/2015 11:45, "Rick Moynihan" <ric...@swirrl.com> wrote:

Hi all,

I have been playing around using ARQ to rewrite queries with Jena 2.13.0
and have encountered what appears to be a bug when roundtripping a valid
SPARQL query through to an SSE and back out as SPARQL.

The original SPARQL query is this:

SELECT (COUNT(*) as ?count) {
  SELECT DISTINCT ?uri ?graph WHERE {
    GRAPH ?graph {
      ?uri ?p ?o .
      }
    } LIMIT 1
}

This parses into the following SSE by going through QueryFactory.create ->
Algebra.compile :

#<OpProject (project (?tripod_count_var)
  (extend ((?tripod_count_var ?.0))
    (group () ((?.0 (count)))
      (distinct
        (project (?uri ?graph)
          (graph ?graph
            (bgp (triple ?uri ?p ?o))))))))

To my eye this looks correct so far... next we round trip it back into a
SPARQL query by using OpAsQuery.asQuery that results in:

#<Query SELECT DISTINCT  (count(*) AS ?tripod_count_var)
WHERE
  { { SELECT  ?uri ?graph
      WHERE
        { GRAPH ?graph
            { ?uri ?p ?o}
        }
    }
  }

This now seems broken...  asQuery has mixed the inner select distinct onto
the outer one.  This appears to happen with all sub selects.  I suspect it
might be due to OpAsQuery.asQuery building only Query object which is
somehow being reused for all sub queries.

I took a look in the unit tests and found that some of the test queries in
TestOpAsQuery are also subject to this bug e.g. the query on line 223:

SELECT ?key ?agg WHERE { { SELECT ?key (COUNT(*) AS ?agg) { ?key ?p ?o }
GROUP BY ?key } }

Though the tests don't seem to currently test for this kind of thing.

Can anyone confirm that this is a bug?

Kind regards,

R.