[GitHub] jena issue #409: JENA-1534: Test for filter-only variables in EXISTS.

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/409
  
Learning a bit more of Jena internals (weather is really bad here in the 
antipodes :-) ). So picked this PR to review, so that I could learn more about 
Jena internals.

Had a look at the previous tickets, and from JENA-1534, looks like the 
query was not considering a variable for a join, I think.

So created an empty persistent dataset in TDB, loaded the `books.ttl` from 
Jena code, and the `yso.ttl` from SKOSMOS in the yso graph (suspected it would 
have some blank nodes, etc).

Tried the query 

```sql
SELECT * WHERE { ?s ?p ?V0 GRAPH ?g { ?sx ?p ?ox FILTER EXISTS { _:b0 ?p 
?V0 } } }
```

And it returned few results, quite quickly. So went and tried `tdbquery` 
from TDB (not TDB2). With following command line (actually in Eclipse, but same 
as):

```shell
tdbquery --explain 
--loc=/home/kinow/Development/java/jena/jena/jena-fuseki2/jena-fuseki-core/run/databases/p1/
 "SELECT * WHERE { ?s ?p ?V0 GRAPH ?g { ?sx ?p ?ox FILTER EXISTS { _:b0 ?p ?V0 
} } }"
```

Adding also `-Dlog4j.configuration=file:///tmp/log4j.properties 
-Dlog4j.debug=true` to see the explain output.

With the code from master, it took <2 seconds to execute the query, and 
produced the following algebra:

```sql
12:36:03 INFO  exec  :: QUERY
  SELECT  *
  WHERE
{ ?s  ?p  ?V0
  GRAPH ?g
{ ?sx  ?p  ?ox
  FILTER EXISTS { _:b0  ?p  ?V0 }
}
}
12:36:03 INFO  exec  :: ALGEBRA
  (sequence
(quadpattern (quad  ?s ?p ?V0))
(filter (exists
   (quadpattern (quad ?g ??0 ?p ?V0)))
  (quadpattern (quad ?g ?sx ?p ?ox
```

So that was a sequence (related to `OpSequence` in Jena, which I'm using to 
search in Eclipse for occurrences to see how it's used). Checked out the branch.

```shell
$ git fetch --all
$ git fetch github refs/pull/409/head:pr-409
$ git checkout pr-409
$ mvn clean install -Pdev -DskipTests
```

Did the `tdbquery` command again, now the algebra became:

```sql
12:41:48 INFO  exec  :: QUERY
  SELECT  *
  WHERE
{ ?s  ?p  ?V0
  GRAPH ?g
{ ?sx  ?p  ?ox
  FILTER EXISTS { _:b0  ?p  ?V0 }
}
}
12:41:48 INFO  exec  :: ALGEBRA
  (join
(quadpattern (quad  ?s ?p ?V0))
(filter (exists
   (quadpattern (quad ?g ??0 ?p ?V0)))
  (quadpattern (quad ?g ?sx ?p ?ox
12:41:48 INFO  exec  :: TDB
  (join
(quadpattern (quad  ?s ?p ?V0))
(filter (exists
   (quadpattern (quad ?g ??0 ?p ?V0)))
  (quadpattern (quad ?g ?sx ?p ?ox
```

A join ! If I understood the tickets, that's the exactly intended 
behaviour, as before the variable in the exist was not being taken into 
consideration to produce a `JOIN` (`OpJoin`). The query also took much longer, 
>10 seconds (I guess SKOSMOS' YSO vocab has something like ~220K triples? The 
Harry Potter books dataset should have like 5? anywho).

So +1 ! LGTM :tada: 

Will probably spend some time reading more of the code base to see if I can 
learn a bit more. And found two posts 
([1](https://gregheartsfield.com/2012/08/26/jena-arq-query-performance.html) 
[2](https://www.slideshare.net/olafhartig/the-semantics-of-sparql) with some 
interesting content. In case you have any other pointers to learn more about 
it, or if I said anything silly, feel free to correct/share, please :-)

*ps: while reading the javadocs of the `Op*` classes, noticed some typos in 
OpSequence. Should I open a pull request for that, or just commit to master?*

```java
-/** A "sequence" is a join-like operation where it is know that the 
- * the output of one step can be fed into the input of the next 
+/** A "sequence" is a join-like operation where it is known that
+ * the output of one step can be fed into the input of the next
  * (that is, no scoping issues arise). */
 
 public class OpSequence extends OpN
```


---

[jira] [Commented] (JENA-1534) Variables in EXISTS must be considered for the join strategy

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1534:
--

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/409
  
Learning a bit more of Jena internals (weather is really bad here in the 
antipodes :-) ). So picked this PR to review, so that I could learn more about 
Jena internals.

Had a look at the previous tickets, and from JENA-1534, looks like the 
query was not considering a variable for a join, I think.

So created an empty persistent dataset in TDB, loaded the `books.ttl` from 
Jena code, and the `yso.ttl` from SKOSMOS in the yso graph (suspected it would 
have some blank nodes, etc).

Tried the query 

```sql
SELECT * WHERE { ?s ?p ?V0 GRAPH ?g { ?sx ?p ?ox FILTER EXISTS { _:b0 ?p 
?V0 } } }
```

And it returned few results, quite quickly. So went and tried `tdbquery` 
from TDB (not TDB2). With following command line (actually in Eclipse, but same 
as):

```shell
tdbquery --explain 
--loc=/home/kinow/Development/java/jena/jena/jena-fuseki2/jena-fuseki-core/run/databases/p1/
 "SELECT * WHERE { ?s ?p ?V0 GRAPH ?g { ?sx ?p ?ox FILTER EXISTS { _:b0 ?p ?V0 
} } }"
```

Adding also `-Dlog4j.configuration=file:///tmp/log4j.properties 
-Dlog4j.debug=true` to see the explain output.

With the code from master, it took <2 seconds to execute the query, and 
produced the following algebra:

```sql
12:36:03 INFO  exec  :: QUERY
  SELECT  *
  WHERE
{ ?s  ?p  ?V0
  GRAPH ?g
{ ?sx  ?p  ?ox
  FILTER EXISTS { _:b0  ?p  ?V0 }
}
}
12:36:03 INFO  exec  :: ALGEBRA
  (sequence
(quadpattern (quad  ?s ?p ?V0))
(filter (exists
   (quadpattern (quad ?g ??0 ?p ?V0)))
  (quadpattern (quad ?g ?sx ?p ?ox
```

So that was a sequence (related to `OpSequence` in Jena, which I'm using to 
search in Eclipse for occurrences to see how it's used). Checked out the branch.

```shell
$ git fetch --all
$ git fetch github refs/pull/409/head:pr-409
$ git checkout pr-409
$ mvn clean install -Pdev -DskipTests
```

Did the `tdbquery` command again, now the algebra became:

```sql
12:41:48 INFO  exec  :: QUERY
  SELECT  *
  WHERE
{ ?s  ?p  ?V0
  GRAPH ?g
{ ?sx  ?p  ?ox
  FILTER EXISTS { _:b0  ?p  ?V0 }
}
}
12:41:48 INFO  exec  :: ALGEBRA
  (join
(quadpattern (quad  ?s ?p ?V0))
(filter (exists
   (quadpattern (quad ?g ??0 ?p ?V0)))
  (quadpattern (quad ?g ?sx ?p ?ox
12:41:48 INFO  exec  :: TDB
  (join
(quadpattern (quad  ?s ?p ?V0))
(filter (exists
   (quadpattern (quad ?g ??0 ?p ?V0)))
  (quadpattern (quad ?g ?sx ?p ?ox
```

A join ! If I understood the tickets, that's the exactly intended 
behaviour, as before the variable in the exist was not being taken into 
consideration to produce a `JOIN` (`OpJoin`). The query also took much longer, 
>10 seconds (I guess SKOSMOS' YSO vocab has something like ~220K triples? The 
Harry Potter books dataset should have like 5? anywho).

So +1 ! LGTM :tada: 

Will probably spend some time reading more of the code base to see if I can 
learn a bit more. And found two posts 
([1](https://gregheartsfield.com/2012/08/26/jena-arq-query-performance.html) 
[2](https://www.slideshare.net/olafhartig/the-semantics-of-sparql) with some 
interesting content. In case you have any other pointers to learn more about 
it, or if I said anything silly, feel free to correct/share, please :-)

*ps: while reading the javadocs of the `Op*` classes, noticed some typos in 
OpSequence. Should I open a pull request for that, or just commit to master?*

```java
-/** A "sequence" is a join-like operation where it is know that the 
- * the output of one step can be fed into the input of the next 
+/** A "sequence" is a join-like operation where it is known that
+ * the output of one step can be fed into the input of the next
  * (that is, no scoping issues arise). */
 
 public class OpSequence extends OpN
```


> Variables in EXISTS must be considered for the join strategy
> 
>
> Key: JENA-1534
> URL: https://issues.apache.org/jira/browse/JENA-1534
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>

[jira] [Commented] (JENA-1535) riot argument "--syntax" should be used as syntax, not as a hint.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1535:
--

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/410#discussion_r184823377
  
--- Diff: jena-cmds/src/main/java/riotcmd/CmdLangParse.java ---
@@ -218,8 +218,14 @@ public ParseRecord parseFile(String filename) {
 RDFParserBuilder builder = RDFParser.create();
 if ( baseURI != null )
 builder.base(baseURI);
-Lang lang = selectLang(null, null, RDFLanguages.NQUADS) ;
-builder.lang(lang);
+if ( modLangParse.getLang() != null )
+// Always use the command line specified synatx.
--- End diff --

Done!


> riot argument "--syntax" should be used as syntax, not as a hint.
> -
>
> Key: JENA-1535
> URL: https://issues.apache.org/jira/browse/JENA-1535
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
>
> {{-\-syntax}} sets the parser builder language hint, which is used as a 
> fallback; the file extension will be used, not the command line syntax. This 
> is a regression introduced when {{RDFParserBuilder}} was incorporated.



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

[GitHub] jena pull request #410: JENA-1535: Parse a specified language if given --syn...

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/410#discussion_r184823377
  
--- Diff: jena-cmds/src/main/java/riotcmd/CmdLangParse.java ---
@@ -218,8 +218,14 @@ public ParseRecord parseFile(String filename) {
 RDFParserBuilder builder = RDFParser.create();
 if ( baseURI != null )
 builder.base(baseURI);
-Lang lang = selectLang(null, null, RDFLanguages.NQUADS) ;
-builder.lang(lang);
+if ( modLangParse.getLang() != null )
+// Always use the command line specified synatx.
--- End diff --

Done!


---

[jira] [Commented] (JENA-1535) riot argument "--syntax" should be used as syntax, not as a hint.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1535:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/jena/pull/410#discussion_r184821458
  
--- Diff: jena-cmds/src/main/java/riotcmd/CmdLangParse.java ---
@@ -218,8 +218,14 @@ public ParseRecord parseFile(String filename) {
 RDFParserBuilder builder = RDFParser.create();
 if ( baseURI != null )
 builder.base(baseURI);
-Lang lang = selectLang(null, null, RDFLanguages.NQUADS) ;
-builder.lang(lang);
+if ( modLangParse.getLang() != null )
+// Always use the command line specified synatx.
--- End diff --

s/synatx/syntax


> riot argument "--syntax" should be used as syntax, not as a hint.
> -
>
> Key: JENA-1535
> URL: https://issues.apache.org/jira/browse/JENA-1535
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
>
> {{-\-syntax}} sets the parser builder language hint, which is used as a 
> fallback; the file extension will be used, not the command line syntax. This 
> is a regression introduced when {{RDFParserBuilder}} was incorporated.



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

[GitHub] jena pull request #410: JENA-1535: Parse a specified language if given --syn...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/jena/pull/410#discussion_r184821458
  
--- Diff: jena-cmds/src/main/java/riotcmd/CmdLangParse.java ---
@@ -218,8 +218,14 @@ public ParseRecord parseFile(String filename) {
 RDFParserBuilder builder = RDFParser.create();
 if ( baseURI != null )
 builder.base(baseURI);
-Lang lang = selectLang(null, null, RDFLanguages.NQUADS) ;
-builder.lang(lang);
+if ( modLangParse.getLang() != null )
+// Always use the command line specified synatx.
--- End diff --

s/synatx/syntax


---

[GitHub] jena pull request #410: JENA-1535: Parse a specified language if given --syn...

[afs]

GitHub user afs opened a pull request:

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

JENA-1535: Parse a specified language if given --syntax.



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

$ git pull https://github.com/afs/jena riot-syntax

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

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


commit 3ff8c96495862271a20f3298950ebb67e5d4a6ee
Author: Andy Seaborne 
Date:   2018-04-27T22:27:38Z

JENA-1535: Parse a specified language if given --syntax.




---

[jira] [Commented] (JENA-1535) riot argument "--syntax" should be used as syntax, not as a hint.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1535:
--

GitHub user afs opened a pull request:

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

JENA-1535: Parse a specified language if given --syntax.



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

$ git pull https://github.com/afs/jena riot-syntax

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

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


commit 3ff8c96495862271a20f3298950ebb67e5d4a6ee
Author: Andy Seaborne 
Date:   2018-04-27T22:27:38Z

JENA-1535: Parse a specified language if given --syntax.




> riot argument "--syntax" should be used as syntax, not as a hint.
> -
>
> Key: JENA-1535
> URL: https://issues.apache.org/jira/browse/JENA-1535
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
>
> {{-\-syntax}} sets the parser builder language hint, which is used as a 
> fallback; the file extension will be used, not the command line syntax. This 
> is a regression introduced when {{RDFParserBuilder}} was incorporated.



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

[jira] [Created] (JENA-1535) riot argument "--syntax" should be used as syntax, not as a hint.

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1535:
---

 Summary: riot argument "--syntax" should be used as syntax, not as 
a hint.
 Key: JENA-1535
 URL: https://issues.apache.org/jira/browse/JENA-1535
 Project: Apache Jena
  Issue Type: Improvement
Affects Versions: Jena 3.7.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne


{{-\-syntax}} sets the parser builder language hint, which is used as a 
fallback; the file extension will be used, not the command line syntax. This is 
a regression introduced when {{RDFParserBuilder}} was incorporated.



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

[jira] [Commented] (JENA-1534) Variables in EXISTS must be considered for the join strategy

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1534:
--

GitHub user afs opened a pull request:

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

JENA-1534: Test for filter-only variables in EXISTS.

Tighten the classifer, assumes proper use of (sequence)
Relates to JENA-1167, JENA-1280.

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

$ git pull https://github.com/afs/jena vars-not-exists

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

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


commit 1bd5fdcf3ac0694e0bbabd2f8e63deb92d3c2bff
Author: Andy Seaborne 
Date:   2018-04-27T18:12:37Z

JENA-1534: Test for filter-only variables in EXISTS.

Tighten the classifer, assumes proper use of (sequence)
Relates to JENA-1167, JENA-1280.




> Variables in EXISTS must be considered for the join strategy
> 
>
> Key: JENA-1534
> URL: https://issues.apache.org/jira/browse/JENA-1534
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> This query has a join between the GRAPH and the pattern before it.
> {noformat}
> SELECT  *
> WHERE
>   { ?s  ?p  ?V0
> GRAPH ?g 
>   { ?sx  ?p  ?ox
> FILTER EXISTS { _:b0  ?p  ?V0 }
>   }
>   }
> {noformat}
> The fact {{?V0}} occurs in the LHS of the join in {{?s  ?p  ?V0}} and in the 
> FILTER but not in the rest of the RHS means the "sequence" transform can not 
> be used.
> Contrast to:
> {noformat}
> SELECT  *
> WHERE
>   { ?s  ?p  ?V1
> GRAPH ?g 
>   { ?sx  ?p  ?ox
> FILTER EXISTS { _:b0  ?p  ?V2 }
>   }
>   }
> {noformat}
> Now {{?V2}} is only in the FILTER so it is safe to transform the join.
> Note that {{?p}} appears in LHS so making it defined in the EXISTS and the 
> sequence transfrom is possible.



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

[GitHub] jena pull request #409: JENA-1534: Test for filter-only variables in EXISTS.

[afs]

GitHub user afs opened a pull request:

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

JENA-1534: Test for filter-only variables in EXISTS.

Tighten the classifer, assumes proper use of (sequence)
Relates to JENA-1167, JENA-1280.

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

$ git pull https://github.com/afs/jena vars-not-exists

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

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


commit 1bd5fdcf3ac0694e0bbabd2f8e63deb92d3c2bff
Author: Andy Seaborne 
Date:   2018-04-27T18:12:37Z

JENA-1534: Test for filter-only variables in EXISTS.

Tighten the classifer, assumes proper use of (sequence)
Relates to JENA-1167, JENA-1280.




---

[jira] [Created] (JENA-1534) Variables in EXISTS must be considered for the join strategy

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1534:
---

 Summary: Variables in EXISTS must be considered for the join 
strategy
 Key: JENA-1534
 URL: https://issues.apache.org/jira/browse/JENA-1534
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.7.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
 Fix For: Jena 3.8.0


This query has a join between the GRAPH and the pattern before it.

{noformat}
SELECT  *
WHERE
  { ?s  ?p  ?V0
GRAPH ?g 
  { ?sx  ?p  ?ox
FILTER EXISTS { _:b0  ?p  ?V0 }
  }
  }
{noformat}
The fact {{?V0}} occurs in the LHS of the join in {{?s  ?p  ?V0}} and in the 
FILTER but not in the rest of the RHS means the "sequence" transform can not be 
used.

Contrast to:
{noformat}
SELECT  *
WHERE
  { ?s  ?p  ?V1
GRAPH ?g 
  { ?sx  ?p  ?ox
FILTER EXISTS { _:b0  ?p  ?V2 }
  }
  }
{noformat}
Now {{?V2}} is only in the FILTER so it is safe to transform the join.

Note that {{?p}} appears in LHS so making it defined in the EXISTS and the 
sequence transfrom is possible.





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

Re: new branch for JPMS?

[Andy Seaborne]

Such a repacking is a "Jena 4" and if we're doing Jena4 the community 
will which so consider other changes as well.


In order to experiment with JPMS, it does not need a branch in the 
codebase - you can clone and develop in a separate github repository 
now.  There is no barrier.


There are many users of jena and there is a significant adoption tail. A 
major version bump with incompatibilities will length the tail. The 
project has been there at Jena1->Jena2. The experience there informed 
how to go Jena2->Jena3 - there was an RDF 1.1 change so Jena3 happened 
as Jena went RDF 1.0 to RDF 1.1.


And not all users are deep technical experts in Java.

We have yet to see just how much JPMS is adopted and at what rate. 
There has not been time yet to see what common, good practice arises.


Maybe there are other ways to get here that do not require a lot of 
change. For example - make one-uber jar of the main modules, name it 
"org.apache.jena".  That is evolutionary for users.


We have automatic-module-name to help the path to JPMS. If, generally, 
AMN turns out to be impractical (and it was a point of contention in the 
Java community vote - a part of the resolution is "we will learn
by releasing" - JPMS is not unchanging yet). or slow in adoption, 
especially in open source, I wouldn't want to waste people's time.


An experiment can lead the change - a release, with all the questions on 
users@ etc, and downstream impacts, needs t be carefully timed and I for 
one would like to see the experiment first.


On 27/04/18 16:03, Christopher Johnson wrote:

Hi,
JPMS is certainly a major change.  I believe that it offers enormous value
to a codebase with strong encapsulation and as such it is similar to OSGI.
The benefits of OSGI are well known, though the implementations are fraught
with complexity.  Comparatively, JPMS is relatively simple.


I see a major issue of timing. What value does it bring to the current 
user/application base and when?


Andy


Retrofitting a robust platform like Jena is without question a big
challenge.  JPMS exposes legacy APIs, so aging dependencies (like log4j 1.x




Only for some logging control and that can be removed.

Personal opinion: drop log4j1, use JUL for logging in tests, in commands 
and builtin for Fuseki.   All quite simple uses. Anything complicates, 
let the user plug their choice as we already do.


Else-project I use Jena with JUL. Works nicely.
There is JUL support code to do much the same as the output for log4j1 
as currently used.


JUL = java.util.logging.




and junit4) will also need to be updated.  Maintaining separate branches
for the long term is indeed a headache.  The branch approach provides a
short term path for learning how to make the break in a major version.

Ultimately, it is a question of compliance and standardization.  Does Jena
want to "buy into" a new global standard or risk being marginalized in the
future?

>

Regarding the composition of the branch, it could start "small".   Perhaps
just with arq, base, and core.  These would be the root packages for those
modules and the ambiguous packages could be moved under them naturally.
The testing infrastructure may need a different approach (i.e. using
JUnit5).

>

Christopher

On Fri, 27 Apr 2018, 15:38 Rob Vesse,  wrote:


I am in the same boat, this sounds like it would quickly become a
maintenance headache.  We don't have the time or people to maintain more
than one branch, particularly if that branch would be a significant
refactor of the code

I am afraid that JPMS is going to kill Java open source efforts in the
same way that .Net profiles killed .Net open source.  It seems to add a lot
of complexity for developers, requires the entire ecosystem to buy in
before it is truly usable i.e. even if we refactor our modules are all our
many dependencies compliant, and doesn't seem like it adds much value to
end users at least from my perspective.

Rob

On 27/04/2018, 14:10, "ajs6f"  wrote:

 I'm not sure how this new branch is supposed to work. If it "just
contains modules compliant with the JPMS and that is tested for JDK9+" but
the current (Maven) modules don't have a one-to-one correspondence with
usable JPMS modules, where are the "modules" for this new branch coming
from?

 Are you suggesting decomposing the entire package structure of the
codebase and recomposing it in a branch? On what basis would packages be
grouped?

 ajs6f

 > On Apr 26, 2018, at 2:58 PM, Christopher Johnson <
chjohnso...@gmail.com> wrote:
 >
 > In reference to a recent PR (https://github.com/apache/jena/pull/401),
I am
 > seeking input on a process to move forward towards JDK9+ (and JPMS)
support
 > in Jena.  As consumers of jena apis, the applications that I am
developing
 > will require JPMS support going forward, so this is an important
issue for
 > my use case.
 >
 > What I have noticed is that there will be 

Re: new branch for JPMS?

[Christopher Johnson]

Hi,
JPMS is certainly a major change.  I believe that it offers enormous value
to a codebase with strong encapsulation and as such it is similar to OSGI.
The benefits of OSGI are well known, though the implementations are fraught
with complexity.  Comparatively, JPMS is relatively simple.

Retrofitting a robust platform like Jena is without question a big
challenge.  JPMS exposes legacy APIs, so aging dependencies (like log4j 1.x
and junit4) will also need to be updated.  Maintaining separate branches
for the long term is indeed a headache.  The branch approach provides a
short term path for learning how to make the break in a major version.

Ultimately, it is a question of compliance and standardization.  Does Jena
want to "buy into" a new global standard or risk being marginalized in the
future?

Regarding the composition of the branch, it could start "small".   Perhaps
just with arq, base, and core.  These would be the root packages for those
modules and the ambiguous packages could be moved under them naturally.
The testing infrastructure may need a different approach (i.e. using
JUnit5).

Christopher

On Fri, 27 Apr 2018, 15:38 Rob Vesse,  wrote:

> I am in the same boat, this sounds like it would quickly become a
> maintenance headache.  We don't have the time or people to maintain more
> than one branch, particularly if that branch would be a significant
> refactor of the code
>
> I am afraid that JPMS is going to kill Java open source efforts in the
> same way that .Net profiles killed .Net open source.  It seems to add a lot
> of complexity for developers, requires the entire ecosystem to buy in
> before it is truly usable i.e. even if we refactor our modules are all our
> many dependencies compliant, and doesn't seem like it adds much value to
> end users at least from my perspective.
>
> Rob
>
> On 27/04/2018, 14:10, "ajs6f"  wrote:
>
> I'm not sure how this new branch is supposed to work. If it "just
> contains modules compliant with the JPMS and that is tested for JDK9+" but
> the current (Maven) modules don't have a one-to-one correspondence with
> usable JPMS modules, where are the "modules" for this new branch coming
> from?
>
> Are you suggesting decomposing the entire package structure of the
> codebase and recomposing it in a branch? On what basis would packages be
> grouped?
>
> ajs6f
>
> > On Apr 26, 2018, at 2:58 PM, Christopher Johnson <
> chjohnso...@gmail.com> wrote:
> >
> > In reference to a recent PR (https://github.com/apache/jena/pull/401),
> I am
> > seeking input on a process to move forward towards JDK9+ (and JPMS)
> support
> > in Jena.  As consumers of jena apis, the applications that I am
> developing
> > will require JPMS support going forward, so this is an important
> issue for
> > my use case.
> >
> > What I have noticed is that there will be breaking changes required
> to
> > structure the code in a way that meets the JPMS "non-interference"
> > specification.[1]  A specific problem occurs when a module does not
> contain
> > a single root package (which is a typical condition in several jena
> > modules).  This results in an "ambiguous module reference" error.  To
> > resolve this ambiguity may require considerable refactoring (e.g.
> moving
> > org.apache.jena.riot to org.apache.jena.arq.riot).  I surmise that
> it is
> > not possible to make these changes and maintain compatibility for
> existing
> > consumers
> >
> > What I would like to propose is a new branch that just contains
> modules
> > compliant with the JPMS and that is tested for JDK9+.  Artifacts
> produced
> > from this branch could be distinguished from master artifacts with an
> > appropriate appendix.
> >
> > Thank you for your consideration,
> > Christopher Johnson
> > Scientific Associate
> > Universitätsbibliothek Leipzig
> >
> > [1]
> http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference
>
>
>
>
>
>
>

Re: new branch for JPMS?

[Rob Vesse]

I am in the same boat, this sounds like it would quickly become a maintenance 
headache.  We don't have the time or people to maintain more than one branch, 
particularly if that branch would be a significant refactor of the code

I am afraid that JPMS is going to kill Java open source efforts in the same way 
that .Net profiles killed .Net open source.  It seems to add a lot of 
complexity for developers, requires the entire ecosystem to buy in before it is 
truly usable i.e. even if we refactor our modules are all our many dependencies 
compliant, and doesn't seem like it adds much value to end users at least from 
my perspective.

Rob

On 27/04/2018, 14:10, "ajs6f"  wrote:

I'm not sure how this new branch is supposed to work. If it "just contains 
modules compliant with the JPMS and that is tested for JDK9+" but the current 
(Maven) modules don't have a one-to-one correspondence with usable JPMS 
modules, where are the "modules" for this new branch coming from?

Are you suggesting decomposing the entire package structure of the codebase 
and recomposing it in a branch? On what basis would packages be grouped?

ajs6f

> On Apr 26, 2018, at 2:58 PM, Christopher Johnson  
wrote:
> 
> In reference to a recent PR (https://github.com/apache/jena/pull/401), I 
am
> seeking input on a process to move forward towards JDK9+ (and JPMS) 
support
> in Jena.  As consumers of jena apis, the applications that I am developing
> will require JPMS support going forward, so this is an important issue for
> my use case.
> 
> What I have noticed is that there will be breaking changes required to
> structure the code in a way that meets the JPMS "non-interference"
> specification.[1]  A specific problem occurs when a module does not 
contain
> a single root package (which is a typical condition in several jena
> modules).  This results in an "ambiguous module reference" error.  To
> resolve this ambiguity may require considerable refactoring (e.g. moving
> org.apache.jena.riot to org.apache.jena.arq.riot).  I surmise that it is
> not possible to make these changes and maintain compatibility for existing
> consumers
> 
> What I would like to propose is a new branch that just contains modules
> compliant with the JPMS and that is tested for JDK9+.  Artifacts produced
> from this branch could be distinguished from master artifacts with an
> appropriate appendix.
> 
> Thank you for your consideration,
> Christopher Johnson
> Scientific Associate
> Universitätsbibliothek Leipzig
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference

Re: new branch for JPMS?

[ajs6f]

I'm not sure how this new branch is supposed to work. If it "just contains 
modules compliant with the JPMS and that is tested for JDK9+" but the current 
(Maven) modules don't have a one-to-one correspondence with usable JPMS 
modules, where are the "modules" for this new branch coming from?

Are you suggesting decomposing the entire package structure of the codebase and 
recomposing it in a branch? On what basis would packages be grouped?

ajs6f

> On Apr 26, 2018, at 2:58 PM, Christopher Johnson  
> wrote:
> 
> In reference to a recent PR (https://github.com/apache/jena/pull/401), I am
> seeking input on a process to move forward towards JDK9+ (and JPMS) support
> in Jena.  As consumers of jena apis, the applications that I am developing
> will require JPMS support going forward, so this is an important issue for
> my use case.
> 
> What I have noticed is that there will be breaking changes required to
> structure the code in a way that meets the JPMS "non-interference"
> specification.[1]  A specific problem occurs when a module does not contain
> a single root package (which is a typical condition in several jena
> modules).  This results in an "ambiguous module reference" error.  To
> resolve this ambiguity may require considerable refactoring (e.g. moving
> org.apache.jena.riot to org.apache.jena.arq.riot).  I surmise that it is
> not possible to make these changes and maintain compatibility for existing
> consumers
> 
> What I would like to propose is a new branch that just contains modules
> compliant with the JPMS and that is tested for JDK9+.  Artifacts produced
> from this branch could be distinguished from master artifacts with an
> appropriate appendix.
> 
> Thank you for your consideration,
> Christopher Johnson
> Scientific Associate
> Universitätsbibliothek Leipzig
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference

[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=16456243#comment-16456243
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Branch created: 
[JENA-632-before-merge](https://github.com/kinow/jena/tree/JENA-632-before-merge).
 Won't delete it this year, in case we need to revisit.

Followed that by:

```
$ git rebase -i HEAD~18
$   # fixed-up all but the first commit
$ git diff JENA-632-before-merge 
$   # empty response, code is identical even though different commit tree
$ git checkout master
$ git merge JENA-632-2
$ git commit --amend
$   # added This closes #114 message to close this pull request
$ mvn clean test install -Pdev
$ git push git-at-apache master
```



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

[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=16456244#comment-16456244
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user asfgit closed the pull request at:

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


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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JENA-632:
--

Commit 4bf5e3c0ad18d61542ce9e37804e8ec727283d96 in jena's branch 
refs/heads/master from [~brunodepau...@yahoo.com.br]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=4bf5e3c ]

JENA-632: Generate JSON from SPARQL directly

This closes #114


> 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

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Branch created: 
[JENA-632-before-merge](https://github.com/kinow/jena/tree/JENA-632-before-merge).
 Won't delete it this year, in case we need to revisit.

Followed that by:

```
$ git rebase -i HEAD~18
$   # fixed-up all but the first commit
$ git diff JENA-632-before-merge 
$   # empty response, code is identical even though different commit tree
$ git checkout master
$ git merge JENA-632-2
$ git commit --amend
$   # added This closes #114 message to close this pull request
$ mvn clean test install -Pdev
$ git push git-at-apache master
```



---

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

[asfgit]

Github user asfgit closed the pull request at:

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


---

[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=16456215#comment-16456215
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/114
  
That works for me.


> 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
  
That works for me.


---

[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=16456212#comment-16456212
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
:tada: should I proceed with the merging? If so, I will squash the 18 
commits into a single one before, as said before, but with a backup branch 
just-in-case. And then start working on the documentation in order to update 
the ticket in JIRA.


> 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

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
:tada: should I proceed with the merging? If so, I will squash the 18 
commits into a single one before, as said before, but with a backup branch 
just-in-case. And then start working on the documentation in order to update 
the ticket in JIRA.


---

[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=16456194#comment-16456194
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184646447
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

Oh, got it! Nice! So no more comments from me :smiley: 


> 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 pull request #114: JENA-632: Generate JSON from SPARQL directly

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184646447
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

Oh, got it! Nice! So no more comments from me :smiley: 


---

[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=16456187#comment-16456187
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184644548
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

For now, Expressions can be done with `BIND` at the end of the `WHERE` 
pattern.

(`sum` is a group-aggregator -- whole different ball game!)


> 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 pull request #114: JENA-632: Generate JSON from SPARQL directly

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184644548
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

For now, Expressions can be done with `BIND` at the end of the `WHERE` 
pattern.

(`sum` is a group-aggregator -- whole different ball game!)


---

[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=16456169#comment-16456169
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184639752
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

> Just use incIndent twice!

Haha, I like it. Done!

>Is it ready to merge? Any area to look at specially? I've used qparse on 
JSON queries and run a few test queries with all the cases I can think of.

I think so ! Only minor thing on my mind now are some expressions. We have 
not implemented support for queries with expressions like

`JSON { 'F' : sum(1+2)} WHERE { } `

Or other functions. Perhaps that could - if necessary - be implemented 
later?


> 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 pull request #114: JENA-632: Generate JSON from SPARQL directly

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184639752
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

> Just use incIndent twice!

Haha, I like it. Done!

>Is it ready to merge? Any area to look at specially? I've used qparse on 
JSON queries and run a few test queries with all the cases I can think of.

I think so ! Only minor thing on my mind now are some expressions. We have 
not implemented support for queries with expressions like

`JSON { 'F' : sum(1+2)} WHERE { } `

Or other functions. Perhaps that could - if necessary - be implemented 
later?


---

[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=16456139#comment-16456139
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184631546
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

Is it ready to merge?  Any area to look at specially? I've used `qparse` on 
JSON queries and run a few test queries with all the cases I can think of.




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

[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=16456138#comment-16456138
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184631233
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

Sorry about the patch - I couldn't figure how to clone your repo because GH 
did not like the fact I already had a repo called "jena". Yes, a constant is 
better.  I thought that 4 looked nicer than 2 and it does not get indented 
further.  Just use `incIndent` twice!


> 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 pull request #114: JENA-632: Generate JSON from SPARQL directly

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184631546
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

Is it ready to merge?  Any area to look at specially? I've used `qparse` on 
JSON queries and run a few test queries with all the cases I can think of.




---

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

[afs]

Github user afs commented on a diff in the pull request:

https://github.com/apache/jena/pull/114#discussion_r184631233
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/serializer/QuerySerializer.java 
---
@@ -142,7 +144,19 @@ public void visitAskResultForm(Query query)
 out.print("ASK") ;
 out.newline() ;
 }
-
+
+@Override
+public void visitJsonResultForm(Query query) {
+out.print("JSON {");
+List terms = new ArrayList<>();
+for (Map.Entry entry : 
query.getJsonMapping().entrySet()) {
--- End diff --

Sorry about the patch - I couldn't figure how to clone your repo because GH 
did not like the fact I already had a repo called "jena". Yes, a constant is 
better.  I thought that 4 looked nicer than 2 and it does not get indented 
further.  Just use `incIndent` twice!


---