[
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16333003#comment-16333003
]
Rick commented on JENA-1468:
----------------------------
Hi Andy,
Thanks for your comments, they're enlightening, but I think perhaps we might
have our wires crossed a little; probably because I should've explained what
I'm doing a bit better.
Basically we've been using JENA for a few years to proxy our triple store and
rewrite incoming SPARQL queries, and then send them to a different database.
So the process is essentially:
SPARQL ---> SSE ----> [Traverse SSE & Rewrite some nodes] ----> convert back to
SPARQL -----> Execute on remote database
Then we capture the responses and rewrite the results on the way back to the
client.
We originally tried doing this with Sesame, but at the time they couldn't print
a parsed query back out; so we switched to using JENA ARQ & SSEs.
So the issue is that during this rewriting step the binding is lost when we
print the query back out from SSE into SPARQL syntax.
I think this statement of yours:
{quote} This is wrong (syntax round trip is not preserved) but harmless. {quote}
might be the main issue I'm trying to report as a bug, though I'm not sure.
Either way it surprised me that there's potentially important data hidden from
the sexpression printing.
{quote}
Try your code on VALUES ?x { undef }
{quote}
This works as I'd expect in my code (though with a simplification) and does
what you suggest it should, i.e. for the query above it converts to:
SELECT ?foo WHERE {
?foo ?bar ?baz .
}
i.e. we lose the values clause altogether, because the fresh/UNDEF variable
?foo is equivalent to the unground ?foo in the triple ?foo ?bar ?baz.
Anyway I've done some playing and it seems that:
OpAsQuery.asQuery(Algebra.compile(QueryFactory.create("SELECT ?foo WHERE { ?foo
?bar ?baz . VALUES ?foo { }}")));
Round trips. Which is surprising because it's not what I see when the
expression is munged/demunged through our clojure zipper with no transformation
applied.
We get:
VALUES ( ) { }
Which we don't want. Not:
VALUES ?foo { }
which we do want.
Does that make sense?
Thanks again.
> Empty VALUES clauses lose variable bindings when compiled to a SSE
> ------------------------------------------------------------------
>
> Key: JENA-1468
> URL: https://issues.apache.org/jira/browse/JENA-1468
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.1.1, Jena 3.2.0, Jena 3.3.0, Jena 3.4.0, Jena
> 3.5.0, Jena 3.6.0
> Reporter: Rick
> Priority: Major
> Labels: SPARQL, sse
>
> Given a SPARQL query like this:
> SELECT ?foo WHERE {
> ?foo ?bar ?baz . # Not essential for problem just to show we can't
> optimise it away.
> VALUES ?foo { }
> }
> If you compile it into an SSE with something like this:
> {{Algebra.compile(QueryFactory.create("SELECT ?foo WHERE \{ ?foo ?bar ?baz .
> VALUES ?foo { }}"));}}
> You end up with a semantically different SSE:
> {{(project (?foo)}}
> {{ (join}}
> {{ (bgp (triple ?foo ?bar ?baz))}}
> {{ (table empty)))}}
> Note how "(table empty)" has lost the ?foo binding, which means that this
> query returns all results for ?foo, where it should return no results.
> I'm not sure how this query should be expressed in SSE form I'd suggest:
> {{(table (vars ?foo) empty)}}
> Though currently this will get simplified in [code like
> this|https://github.com/apache/jena/blob/94eb3fc99ba1ff3991a629fffa6e6cf8b52d6c53/jena-arq/src/main/java/org/apache/jena/sparql/sse/builders/BuilderTable.java#L55-L64]
> into an EmptyTable if you do something like:
> {{BuilderTable.build(Item.createList((SSE.parse("(table (vars ?foo)
> empty)")));}}
> Additionally it appears quite a bit of code carries through this assumption
> that an [empty table will never have a
> binding|https://github.com/apache/jena/blob/94eb3fc99ba1ff3991a629fffa6e6cf8b52d6c53/jena-arq/src/main/java/org/apache/jena/sparql/algebra/table/TableEmpty.java#L57].
> As far as I can tell this issue effects many prior versions of JENA including
> 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
