Hey, this is probably not directly relevant to your use case, but once again I'd like to suggest using SPIN Vocabulary as an API-neutral way to represent and manage SPARQL natively as RDF: http://spinrdf.org/sp.html
I know Sesame has plans to implement support for SPIN: https://openrdf.atlassian.net/browse/SES-1840 Martynas On Thu, Jun 4, 2015 at 5:23 PM, Rick Moynihan <ric...@swirrl.com> wrote: > On 4 June 2015 at 14:08, Andy Seaborne <a...@apache.org> wrote: > >> Hi Rick, >> >> Are you in a position where you give some background on what you're trying >> to achieve overall? >> > > Sure. Basically we're porting some existing work of ours which was based > on Sesame, which would rewrite queries (and then the results on the way > out) using sesame's AST. We're not doing anything especially fancy... > mostly simple URI substitutions on URI constants, both on the query and > then the results; so from the query side the transformation is essentially > invisible. > > This worked great, whilst the we were using the sesame native store, as > we'd essentially go from SPARQL -> AST -> rewritten AST -> execution & > results. However we now wish to make this same code work with remote > stores, which essentially means we have to convert the rewritten queries > back into valid SPARQL queries. > > We don't care about syntactic or structural differences in queries, that > occur, but semantically the queries need to be isomorphic. We originally > tried using sesame's query renderer, but it doesn't support SPARQL 1.1 So > we thought we'd port this code to use ARQ. > > and inline ... >> >> On 04/06/15 13:49, Rick Moynihan wrote: >> >>> Hi Rob, >>> >>> Firstly thanks for filing the bug for me. >>> >>> Secondly in the case you cite, I don't understand why the query you cite: >>> >>> SELECT * { >>> SELECT ?x { ?x a ?type } >>> } >>> >>> Isn't converted into the SSE: >>> >>> (project (?x ?type) >>> (project (?x) >>> (bgp >>> (triple ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> >>> ?type)))) >>> >>> >> I hope not - that is the algebra for: >> >> SELECT ?x ?type { >> SELECT ?x { ?x a ?type } >> >> same effect, different way of writing it. >> > > I expanded the * partly because I didn't know whether SSE's represent > wildcards. For my particular use case either way is fine. > > Rewriting does no "optimization" however simple. >> >> Or the semantically equivalent: >>> >>> (project (?x ?type) >>> (bgp >>> (triple ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?type))) >>> >>> Both of which will OpAsQuery.asQuery back into a semantically equivalent >>> SPARQL query. >>> >>> I clearly don't quite understand the role of the SSE's and the various >>> representations of Query inside ARQ. >>> >> >> SSE is the syntax in which the ARQ internal algebra can be written out and >> read in. We do loosely talk about SSE for the alegbra but in fact theer >> are lots of other things that can be written in SSE. Includind RDF data! >> >> http://jena.apache.org/documentation/notes/sse.html >> >> SSE is just a syntax. >> >> >>> Essentially I was wanting to use the SSE's to convert a SPARQL query into >>> a >>> tree, rewrite the query tree, and convert it back into SPARQL with >>> OpAsQuery. >>> >> >> If you want to do transforms that restructure the query, that's the way >> I'd do it. >> > > That's a relief. As I've already spent 2 days porting my rewriting code to > ARQ and this style, and my only failing test case is currently with nested > sub queries. > > I think I'd misread Robs answer with regards to the semantics of * and > subqueries, and thought it was returning a different query! > > So am I right that once JENA-954 is fixed, round tripping should always be > possible, and should always yield a semantically equivalent query? > > > If you want more of a surface manipulation, and only such manipulations, >> e.g. rename a variable, then a transformation of the query syntax tree >> might be easier. I have some code for this I can contribute (written as an >> alternative to the query builder / parameterized query code). >> >> https://github.com/afs/AFS-Dev/tree/master/src/main/java/element >> >> If you think you are ever going to need the complicated part, investing in >> setting up the op based one is better. AST manipulation is a bit of a dead >> end. >> >> The OpAsQuery contract can't be query=>op=>exactly the same query because >> there ways to write two queries that lead to "the same" algebra. >> >> ARQ executes the algebra so the Op=>Query step isn't needed (or desirable). >> >> I had assumed that aside from handling the trivialities around restoring >>> the outer queries type (e.g. CONSTRUCT/ASK/DESRIBE etc...) that this would >>> work, and that SPARQL queries would be round tripable. >>> >>> What is the reasoning for this property not holding? I understand that >>> SSE's can express things that can't be expressed in SPARQL, presumably >>> useful once the SSE has been optimized; but why isn't every valid SPARQL >>> query round tripable, as suggested above? >>> >> >> We hope to have that contract (essentially, reverse the syntax to algebra >> algorithm in the SPARQL spec). >> > > Amazing! I think this answers my above question. > > 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? > > > 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. >>>> >>> >>> >>> >>> >>> >>> >>