[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-632:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/114
  
Conversion code (draft): 2dd4418a22 (on a branch in my GH at the moment).

The code is in `RDFTerm2Json.fromNode`.


> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: java, javacc
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena issue #114: JENA-632: Generate JSON from SPARQL directly

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/114
  
Conversion code (draft): 2dd4418a22 (on a branch in my GH at the moment).

The code is in `RDFTerm2Json.fromNode`.


---

[jira] [Commented] (JENA-1507) GROUP BY and aggregates when there are no matching of the WHERE pattern.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1507:
--

GitHub user afs opened a pull request:

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

JENA-1507: Fixes for aggregates when no WHERE match.

This includes the two commits of PR #381.

Commit 8a64ffee are the actual functional changes for JENA-1507.

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

$ git pull https://github.com/afs/jena jena-1507_aggregates

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

https://github.com/apache/jena/pull/382.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 #382


commit eb3b9beda79d35347daea1925752306b4ef5911f
Author: Andy Seaborne 
Date:   2018-03-13T13:59:35Z

Remove test printing. Remove info warnings.

commit 459a2b88f5e9544e5ddcc9979914eb0dca14b0d7
Author: Andy Seaborne 
Date:   2018-03-13T14:00:06Z

Reformat

commit 8a64ffeef483df37bcbd313ada28104a945d2027
Author: Andy Seaborne 
Date:   2018-03-13T15:21:29Z

JENA-1507: No rows when no match if GROUP BY used




> GROUP BY and aggregates when there are no matching of the WHERE pattern.
> 
>
> Key: JENA-1507
> URL: https://issues.apache.org/jira/browse/JENA-1507
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> There are two bugs in ARQs handling of grouping when there are no results in 
> the WHERE clause.
> When there is a GROUP BY, the outcome should be no rows. 
>  * JENA-1487
>  * [users list 
> discussion|https://lists.apache.org/thread.html/72c2045e639c589880619443beafec5be963733e0f9f0887e134d467@%3Cusers.jena.apache.org%3E]
> When there is no GROUP BY, no aggregates, and no pattern match, the result 
> should be one row of no columns; when there is no GROUP BY, the result is 
> always one row.  It returns zero rows (v3.6.0 and before).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #382: JENA-1507: Fixes for aggregates when no WHERE match.

[afs]

GitHub user afs opened a pull request:

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

JENA-1507: Fixes for aggregates when no WHERE match.

This includes the two commits of PR #381.

Commit 8a64ffee are the actual functional changes for JENA-1507.

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

$ git pull https://github.com/afs/jena jena-1507_aggregates

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

https://github.com/apache/jena/pull/382.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 #382


commit eb3b9beda79d35347daea1925752306b4ef5911f
Author: Andy Seaborne 
Date:   2018-03-13T13:59:35Z

Remove test printing. Remove info warnings.

commit 459a2b88f5e9544e5ddcc9979914eb0dca14b0d7
Author: Andy Seaborne 
Date:   2018-03-13T14:00:06Z

Reformat

commit 8a64ffeef483df37bcbd313ada28104a945d2027
Author: Andy Seaborne 
Date:   2018-03-13T15:21:29Z

JENA-1507: No rows when no match if GROUP BY used




---

[jira] [Commented] (JENA-1507) GROUP BY and aggregates when there are no matching of the WHERE pattern.

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1507:
-

The SPARQL spec is wrong as well:

In the definition of "Group", 
[https://www.w3.org/TR/sparql11-query/#defn_algGroup]

If the pattern does not match, Ω is empty and so "Group(exprlist, Ω)" is the 
empty set ∅ because it says at the end "| μ in Ω }"; Ω is empty so there is 
for-each evaluation.

Once "Group(exprlist, Ω)" is the empty set, it is identical to "GROUP BY" and 
no match, ending up in no rows.

But, for example, COUNT(*) is supposed to be 0 in the single row. There is 
always a single row when there is no GROUP  BY, even if it is a row of no 
columns (no aggregate functions). (It is not possible to write  that in SPARQL 
- an aggregate is needed to trigger being all-one-group).

 

> GROUP BY and aggregates when there are no matching of the WHERE pattern.
> 
>
> Key: JENA-1507
> URL: https://issues.apache.org/jira/browse/JENA-1507
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> There are two bugs in ARQs handling of grouping when there are no results in 
> the WHERE clause.
> When there is a GROUP BY, the outcome should be no rows. 
>  * JENA-1487
>  * [users list 
> discussion|https://lists.apache.org/thread.html/72c2045e639c589880619443beafec5be963733e0f9f0887e134d467@%3Cusers.jena.apache.org%3E]
> When there is no GROUP BY, no aggregates, and no pattern match, the result 
> should be one row of no columns; when there is no GROUP BY, the result is 
> always one row.  It returns zero rows (v3.6.0 and before).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1487) Incorrect SPARQL query result set when applying ORDER BY after an empty GROUP BY

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1487:
-

See JENA-1507.

> Incorrect SPARQL query result set when applying ORDER BY after an empty GROUP 
> BY
> 
>
> Key: JENA-1487
> URL: https://issues.apache.org/jira/browse/JENA-1487
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Claus Stadler
>Priority: Major
>
> Ordering an empty result set must not introduce additional bindings, but this 
> happens with the following example (run on an arbitrary dataset - including 
> an empty one):
> {code:bash}
> ./fuseki-server --file=test.ttl /foobar
> {code}
> The Json below is obtained from the Fuski bundle; but I noted this issue 
> first using the ARQ API, where the incorrect result set contains a single 
> BindingProjectNamed instance.
> {code:sql}
> SELECT ?s
> WHERE {
>   ?s ?p ?o
>   FILTER(false)
> }
> GROUP BY ?s
> ORDER BY DESC(COUNT(?o))
> {code}
> {code:json}
> {
>   "head": {
> "vars": [ "s" ]
>   } ,
>   "results": {
> "bindings": [
>   {
> # NOTE THIS EMPTY BINDING HERE!
>   }
> ]
>   }
> }
> {code}
> The result set is correct without the ORDER BY:
> {code:sql}
> SELECT ?s
> WHERE {
>   ?s ?p ?o
>   FILTER(false)
> }
> GROUP BY ?s
> {code}
> {code:json}
> {
>   "head": {
> "vars": [ "s" ]
>   } ,
>   "results": {
> "bindings": [
> # CORRECT  
> ]
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1507) GROUP BY and aggregates when there are no matching of the WHERE pattern.

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1507:
---

 Summary: GROUP BY and aggregates when there are no matching of the 
WHERE pattern.
 Key: JENA-1507
 URL: https://issues.apache.org/jira/browse/JENA-1507
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.6.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne


There are two bugs in ARQs handling of grouping when there are no results in 
the WHERE clause.

When there is a GROUP BY, the outcome should be no rows. 
 * JENA-1487
 * [users list 
discussion|https://lists.apache.org/thread.html/72c2045e639c589880619443beafec5be963733e0f9f0887e134d467@%3Cusers.jena.apache.org%3E]

When there is no GROUP BY, no aggregates, and no pattern match, the result 
should be one row of no columns; when there is no GROUP BY, the result is 
always one row.  It returns zero rows (v3.6.0 and before).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] jena pull request #381: Reformat QueryIterGroup; no test out from TestParame...

[afs]

GitHub user afs opened a pull request:

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

Reformat QueryIterGroup; no test out from TestParameterizedSparqlString

Reformat `QueryIterGroup` prior to work on aggregates.
Remove print out in from `TestParameterizedQueryString`.
Remove a couple info warnings.


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

$ git pull https://github.com/afs/jena cleanup

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

https://github.com/apache/jena/pull/381.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 #381


commit eb3b9beda79d35347daea1925752306b4ef5911f
Author: Andy Seaborne 
Date:   2018-03-13T13:59:35Z

Remove test printing. Remove info warnings.

commit 459a2b88f5e9544e5ddcc9979914eb0dca14b0d7
Author: Andy Seaborne 
Date:   2018-03-13T14:00:06Z

Reformat




---

[jira] [Commented] (JENA-1488) SelectiveFoldingFilter for jena-text

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on JENA-1488:
--

>The DefinedFilter solution sounds like the best from my perspective too.

Agreed! Just re-read [~code-ferret]'s previous comments, then jumped to have a 
look at TextIndexLuceneAssembler/TextIndexLucene. And I believe I'm 
understanding more what he meant. Will wait for his PR to review/test and see 
how the SelectiveFoldingFilter would fit in the solution (I believe I will work 
like a charm!).

>I'd still prefer the SelectiveFoldingFilter to live in the Jena codebase (for 
>reasons of convenience stated above).

Agreed. IIUC, with the DefinedFilter/DefinedTokenizer approach, we will be able 
to use the SelectiveFoldingFilter from my PR, or any other filter/tokenizer 
combination from Lucene :D

 

> SelectiveFoldingFilter for jena-text
> 
>
> Key: JENA-1488
> URL: https://issues.apache.org/jira/browse/JENA-1488
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Text
>Affects Versions: Jena 3.6.0
>Reporter: Osma Suominen
>Assignee: Bruno P. Kinoshita
>Priority: Major
>
> Currently there's some support for accent folding in jena-text, because 
> Lucene provides an ASCIIFoldingFilter. When this filter is enabled, a search 
> for "deja vu" will match the literal "déjà vu" in the data.
> But we can't use it here at the National Library of Finland (for Finto.fi / 
> Skosmos), because it folds too much! In the Finnish alphabet, in addition to 
> the Latin a-z (which are in ASCII) we use the letters åäö and these should 
> not be folded to ASCII. So we need a Lucene analyzer that can be configured 
> with an exclude list, something like 
>  
> new SelectiveFoldingFilter(String excludeChars) 
>  
> and that can be also be configured via the Jena assembler just like other 
> analyzers supported by jena-text. 
>  
> This was also briefly discussed on the skosmos-users mailing list: 
> [https://groups.google.com/d/msg/skosmos-users/x3zR_uRBQT0/Q90-O_iDAQAJ] 
> Apparently Norwegians have the same problem...
> I've discussed this with [~kinow] and he has some initial code to implement 
> this feature, so I think we can turn this into a PR fairly soon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)