Re: Possible Bug Roundtripping SPARQL to an SSE and back

[Andy Seaborne]

On 04/06/15 16:23, Rick Moynihan wrote:

I noticed that JENA-954 has been scheduled for 3.0.0; is that release
expected anytime soon?  I'm not sure I know enough about JENA to provide a
patch for this issue yet, but if we could assemble one, could it be
included in an earlier release?

There are development SNAPSHOT builds for jena3:

https://repository.apache.org/content/repositories/snapshots/org/apache/jena/


http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html

    Package renaming : com.hp.hpl.jena becomes org.apache.jena.
    RDF 1.1 Semantics for plain literals
    Persistent data (TDB, SDB) should be reloaded.

        Andy

R.


  Thanks again for filing the bug report for me, and answering my questions.

Kind regards,

R.

On 4 June 2015 at 12:28, Rob Vesse <rve...@dotnetrdf.org> wrote:

  Rick

Yes this does look like a bug

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.