Re: FILTER EXISTS evaluation of different triple stores

[Lorenz B.]

Hi,

thank you for the interesting pointers.


On 29.01.2018 17:01, Andy Seaborne wrote:
> EXISTS is important when verifying data (SHACL, and I presume, ShEX).
> NOT EXISTS is probably more common in query situations.
I agree, never used EXISTS without NOT, though indeed I just use SPARQL
for querying.
>
> What I'd like to see in this paper is discussion about SQL because, in
> the abstract, this isn't much different from SQL features.
>
> In practical usage I've seen, the graph pattern in EXIST / NOT EXISTS
> do not seem to be very complicated - BGP, FILTER, GRAPH.
Sometimes, I use NOT EXISTS in combination with sub-queries but to be
honest, I never thought about any possible issue in doing so. Clearly,
this is because I didn't read the eval specs carefully enough to
recognize that only the GP case is covered.
>
> There is/was a W3C community group to move this forward.
>
> The SPARQL 1.1 spec replaces variables by their value which leads to
> some problems documented at:
>
>
> https://w3c.github.io/sparql-exists/docs/sparql-exists.html#identified-issues
>
>
>
> The community group is inactive - there are (were) two proposals,
>
> One proposal (disclosure - this is mine)
>
>   https://w3c.github.io/sparql-exists/docs/sparql-exists.html#proposal-b
>
> is based on the idea of SQL correlated subquery; the variables in the
> inner query take only the values of the current binding by joining,
> where the variables are set, with a VALUES table. It leaves the
> variables in-place and makes sure they are bound to the value in the
> row being filtered (rather than replace it by its row binding).  
> Several spec problems go away as the variable is still there. It is a
> purely algebra/execution solution.  It works for nested patterns and
> is closer to the spec.
>
> The other proposal (Peter Peter Patel-Schneider)
>
>   https://w3c.github.io/sparql-exists/docs/sparql-exists.html#proposal-a
>
> is based on injecting the variable values to be joined after
> sub-patterns are evaluated. It is a mix of syntax and execution. It is
> simpler to describe, but not implement. It does not apply to nested
> patterns and it has had less investigation.
Well, in that case I'd also go for the first proposal.

Just as a follow up question:

Given that you'd have been decided for one of the proposals, how would
the whole process continue? I mean, how does it work in revising the
specs? SPARQL 1.2 or is it possible to modify an existing spec? I guess
this would be strange right, because somebody would have to tell
developers of the existing triple stores that there have to be done some
changes in their implementation.


Lorenz
>
>     Andy
>
> On 28/01/18 10:56, Lorenz B. wrote:
>> Hi all,
>>
>> just if somebody is interested in reading about the different behavior
>> of triple stores when evaluating FILTER EXISTS. [1]
>>
>> Not sure how often this feature is used nowadays, but anyways
>> interesting to know ( though I'd never write the SPARQL query as given
>> in the example of the paper, seems odd)
>>
>>
>> Cheers,
>>
>> Lorenz
>>
>> [1] https://arxiv.org/pdf/1801.04387.pdf
>>

Re: CMS diff: Jena Full Text Search

[Andy Seaborne]

Done.

I think all the Unicode characters got into the final result correctly.

Andy

On 28/01/18 16:45, Chris Tomlinson wrote:

Andy,

Yes I was just word-smithing and tweaking punctuation.

Thanks,
Chris



On Jan 28, 2018, at 10:30 AM, Andy Seaborne  wrote:

Chris,

There's 3 diffs a few minutes apart.

This 3rd CMS diff is the right one to apply and includes the superceeds the 
previous ones?

Andy

On 22/01/18 03:15, Chris Tomlinson wrote:

Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://jena.apache.org/documentation%2Fquery%2Ftext-query.mdtext
Chris Tomlinson
Index: trunk/content/documentation/query/text-query.mdtext
===
--- trunk/content/documentation/query/text-query.mdtext (revision 1821823)
+++ trunk/content/documentation/query/text-query.mdtext (working copy)
@@ -1,5 +1,7 @@
  Title: Jena Full Text Search
  +Title: Jena Full Text Search
+
  This extension to ARQ combines SPARQL and full text search via
  [Lucene](https://lucene.apache.org) 6.4.1 or
  [ElasticSearch](https://www.elastic.co) 5.2.1 (which is built on
@@ -231,7 +233,7 @@
The most general form is:
 - (?s ?score ?literal ?g) text:query (property 'query string' limit 
'lang:xx')
+ ( ?s ?score ?literal ?g ) text:query ( property 'query string' limit 
'lang:xx' 'highlight:yy' )
 Input arguments:
  @@ -241,13 +243,13 @@
  | query string  | Lucene query string fragment   |
  | limit | (optional) `int` limit on the number of results   |
  | lang:xx   | (optional) language tag spec   |
-| highlight:xx  | (optional) highlighting options|
+| highlight:yy  | (optional) highlighting options|
The `property` URI is only necessary if multiple properties have been
  indexed and the property being searched over is not the [default field
  of the index](#entity-map-definition).
  -The `query string` syntax conforms the underlying index 
[Lucene](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
+The `query string` syntax conforms to the underlying index 
[Lucene](http://lucene.apache.org/core/6_4_1/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description)
  or
  
[Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl.html).
 In the case of Lucene the syntax is restricted to `Terms`, `Term modifiers`, 
`Boolean Operators` applied to `Terms`, and `Grouping` of terms. _No use of 
`Fields` within the `query string` is supported._
  @@ -258,9 +260,9 @@
  indexed with the tag _xx_. Searches may be restricted to field values with no
  language tag via `"lang:none"`.
  -The `highlight:xx` specification is an optional string where _xx_ are 
options that control the highlighting of search result literals. See 
[below](#highlighting) for details.
+The `highlight:yy` specification is an optional string where _yy_ are options 
that control the highlighting of search result literals. See 
[below](#highlighting) for details.
  -If both `limit` and one or more of `lang:xx` or `highlight:xx` are present, 
then `limit` must precede these arguments.
+If both `limit` and one or more of `lang:xx` or `highlight:yy` are present, 
then `limit` must precede these arguments.
If only the query string is required, the surrounding `( )` _may be_ 
omitted.
  @@ -499,7 +501,7 @@
 Highlighting
  -The highlighting option uses the Lucene `Highlighter` and 
`SimpleHTMLFormatter` to insert highlighting markup into the literals returned 
from search results (hence the text dataset must be configured to store the 
literals). The highlighted results are returned via the _literal_ output 
argument.
+The highlighting option uses the Lucene `Highlighter` and 
`SimpleHTMLFormatter` to insert highlighting markup into the literals returned 
from search results (hence the text dataset must be configured to store the 
literals). The highlighted results are returned via the _literal_ output 
argument. This highlighting feature, introduced in version 3.7.0, does not 
require re-indexing by Lucene.
The simplest way to request highlighting is via `'highlight:'`. This will 
apply all the defaults:
  @@ -521,7 +523,7 @@
"the quick ↦brown fox↤ jumped over the lazy baboon"
  -The `RIGHT_ARROW` is Unicode \u21a6 and the `LEFT_ARROW` is Unicode \u21a4. 
These are chosen to be single characters that in most situations will be very 
unlikely to occur in resulting literals. The `fragSize` of 128 is chosen to be 
large enough that in many situations the matches will result in single 
fragments. If the literal is larger than 128 characters and there are several 
matches in the literal then there may be additional fragments separated by the 
`DIVIDES`, Unicode \u2223.
+The `RIGHT_ARROW` is Unicode, \u21a6, and the `LEFT_ARROW` 

[GitHub] jena pull request #347: No instances for TDB and TDB2 classes

[afs]

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/347

No instances for TDB and TDB2 classes

These classes are content and function holders only.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena tdb-closed

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/347.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #347


commit 17acb26cbe2cdbb1c01bb469284fb0ff121f4278
Author: Andy Seaborne 
Date:   2018-01-29T21:38:54Z

No instances for TDB and TDB2 classes




---

[jira] [Commented] (JENA-1468) Empty VALUES clauses lose variable bindings when compiled to a SSE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343650#comment-16343650
 ] 

ASF GitHub Bot commented on JENA-1468:
--

Github user RickMoynihan commented on the issue:

https://github.com/apache/jena/pull/345
  
Thanks for the info @afs, was really just checking incase there was a 
release planned in the next week or so.  

Looks like I'll be deploying an internal build to our private artifact 
bucket then :-)


> 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)

[GitHub] jena issue #345: JENA-1468: Retain variables in op (table)

[RickMoynihan]

Github user RickMoynihan commented on the issue:

https://github.com/apache/jena/pull/345
  
Thanks for the info @afs, was really just checking incase there was a 
release planned in the next week or so.  

Looks like I'll be deploying an internal build to our private artifact 
bucket then :-)


---

Re: FILTER EXISTS evaluation of different triple stores

[Andy Seaborne]

EXISTS is important when verifying data (SHACL, and I presume, ShEX). 
NOT EXISTS is probably more common in query situations.


What I'd like to see in this paper is discussion about SQL because, in 
the abstract, this isn't much different from SQL features.


In practical usage I've seen, the graph pattern in EXIST / NOT EXISTS do 
not seem to be very complicated - BGP, FILTER, GRAPH.


There is/was a W3C community group to move this forward.

The SPARQL 1.1 spec replaces variables by their value which leads to 
some problems documented at:



https://w3c.github.io/sparql-exists/docs/sparql-exists.html#identified-issues


The community group is inactive - there are (were) two proposals,

One proposal (disclosure - this is mine)

  https://w3c.github.io/sparql-exists/docs/sparql-exists.html#proposal-b

is based on the idea of SQL correlated subquery; the variables in the 
inner query take only the values of the current binding by joining, 
where the variables are set, with a VALUES table. It leaves the 
variables in-place and makes sure they are bound to the value in the row 
being filtered (rather than replace it by its row binding).   Several 
spec problems go away as the variable is still there. It is a purely 
algebra/execution solution.  It works for nested patterns and is closer 
to the spec.


The other proposal (Peter Peter Patel-Schneider)

  https://w3c.github.io/sparql-exists/docs/sparql-exists.html#proposal-a

is based on injecting the variable values to be joined after 
sub-patterns are evaluated. It is a mix of syntax and execution. It is 
simpler to describe, but not implement. It does not apply to nested 
patterns and it has had less investigation.


Andy

On 28/01/18 10:56, Lorenz B. wrote:

Hi all,

just if somebody is interested in reading about the different behavior
of triple stores when evaluating FILTER EXISTS. [1]

Not sure how often this feature is used nowadays, but anyways
interesting to know ( though I'd never write the SPARQL query as given
in the example of the paper, seems odd)


Cheers,

Lorenz

[1] https://arxiv.org/pdf/1801.04387.pdf

[jira] [Commented] (JENA-1468) Empty VALUES clauses lose variable bindings when compiled to a SSE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343538#comment-16343538
 ] 

ASF GitHub Bot commented on JENA-1468:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/345
  
@RickMoynihan : thanks for looking at it.

Merge : soon, because you provide independent checking. It will then be in 
the daily development build but that is not a formal release.

Release : this depends on people-time, and realistically, we can't make 
solid timelines. We do run "releasable master" means that the master branch is 
releasable most of the time so the dev builds are realistic.

The general project hope is every 3-4 months, though we had an out-of-step 
release at 3.6.0. That is not a commitment though!


> 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)

[GitHub] jena issue #345: JENA-1468: Retain variables in op (table)

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/345
  
@RickMoynihan : thanks for looking at it.

Merge : soon, because you provide independent checking. It will then be in 
the daily development build but that is not a formal release.

Release : this depends on people-time, and realistically, we can't make 
solid timelines. We do run "releasable master" means that the master branch is 
releasable most of the time so the dev builds are realistic.

The general project hope is every 3-4 months, though we had an out-of-step 
release at 3.6.0. That is not a commitment though!


---

Re: FILTER EXISTS evaluation of different triple stores

[ajs6f]

There is a W3C Community Group discussing related issues, chaired by Andy. 
Unfortunately, I think progress has stalled on disagreements as to the best 
road forward.

ajs6f

> On Jan 28, 2018, at 5:56 AM, Lorenz B.  wrote:
> 
> Hi all,
> 
> just if somebody is interested in reading about the different behavior
> of triple stores when evaluating FILTER EXISTS. [1]
> 
> Not sure how often this feature is used nowadays, but anyways
> interesting to know ( though I'd never write the SPARQL query as given
> in the example of the paper, seems odd)
> 
> 
> Cheers,
> 
> Lorenz
> 
> [1] https://arxiv.org/pdf/1801.04387.pdf
> 

[jira] [Commented] (JENA-1468) Empty VALUES clauses lose variable bindings when compiled to a SSE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343411#comment-16343411
 ] 

ASF GitHub Bot commented on JENA-1468:
--

Github user RickMoynihan commented on the issue:

https://github.com/apache/jena/pull/345
  
@afs This is fantastic thank you so much!

I've checked out the branch from your repo, built a local version and can 
confirm it fixes the issue for us.

Do you have any idea when this will be merged and a `3.7.0` release of JENA 
released?


> 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)

[GitHub] jena issue #345: JENA-1468: Retain variables in op (table)

[RickMoynihan]

Github user RickMoynihan commented on the issue:

https://github.com/apache/jena/pull/345
  
@afs This is fantastic thank you so much!

I've checked out the branch from your repo, built a local version and can 
confirm it fixes the issue for us.

Do you have any idea when this will be merged and a `3.7.0` release of JENA 
released?


---

[jira] [Commented] (JENA-1468) Empty VALUES clauses lose variable bindings when compiled to a SSE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343243#comment-16343243
 ] 

ASF GitHub Bot commented on JENA-1468:
--

Github user afs commented on the issue:

https://github.com/apache/jena/pull/345
  
It does not need to change. It will behave as before.

The changes here differentiate between a table that is of class 
`TableEmpty`, using function `TableEmpty.isTableEmpty`, and a table that 
evaluates to empty (no rows) using method `Table.isEmpty`.  Previously, there 
was only the latter method.

`VALUES ?foo {}` creates algebra `TableN` with declared variable `?foo` and 
no rows.  It printed (incorrectly) as `(table empty)` but internally it was a 
`TableN` and method `isEmpty` is true (no rows).

Now it prints as `(table (vars ?foo))`. There is no change to the data 
structure in the algebra.

The difference is on conversion to a string, and on `.equals`, then only if 
read in again because it was not round-tripping the data structure, even if it 
evaluated to the same thing. Declared variables make no difference to the value 
of a table and that follows the SPARQL 1.1 spec exactly.

As it makes no eval difference, we haven't noticed before. 



> 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)

[GitHub] jena issue #345: JENA-1468: Retain variables in op (table)

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/345
  
It does not need to change. It will behave as before.

The changes here differentiate between a table that is of class 
`TableEmpty`, using function `TableEmpty.isTableEmpty`, and a table that 
evaluates to empty (no rows) using method `Table.isEmpty`.  Previously, there 
was only the latter method.

`VALUES ?foo {}` creates algebra `TableN` with declared variable `?foo` and 
no rows.  It printed (incorrectly) as `(table empty)` but internally it was a 
`TableN` and method `isEmpty` is true (no rows).

Now it prints as `(table (vars ?foo))`. There is no change to the data 
structure in the algebra.

The difference is on conversion to a string, and on `.equals`, then only if 
read in again because it was not round-tripping the data structure, even if it 
evaluated to the same thing. Declared variables make no difference to the value 
of a table and that follows the SPARQL 1.1 spec exactly.

As it makes no eval difference, we haven't noticed before. 



---

[GitHub] jena issue #345: JENA-1468: Retain variables in op (table)

[rvesse]

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/345
  
Does 
https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/TransformPromoteTableEmpty.java#L160
 need to change to use the new test?


---

[jira] [Commented] (JENA-1468) Empty VALUES clauses lose variable bindings when compiled to a SSE

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343161#comment-16343161
 ] 

ASF GitHub Bot commented on JENA-1468:
--

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/345
  
Does 
https://github.com/apache/jena/blob/cc038809fb622779933831011909714e22ef494c/jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/TransformPromoteTableEmpty.java#L160
 need to change to use the new test?


> 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)