[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/120#issuecomment-169384106
  
Third time is the charm!

I think this time I have a good factoring that begins to separate the 
notion of ordering from the kind of data structure which stores the nodes. This 
will be useful for JENA-1084, which I am also working on. I wish this could 
look a little cleaner, but I cannot separate the state for ordering and the 
state for node storage in the nicest way because of single-inheritance, or at 
least I can't see how to do that. (Suggestions welcome!)


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1083: Factoring tuple ordering into TupleM...

[ajs6f]

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/120#issuecomment-169384106
  
Third time is the charm!

I think this time I have a good factoring that begins to separate the 
notion of ordering from the kind of data structure which stores the nodes. This 
will be useful for JENA-1084, which I am also working on. I wish this could 
look a little cleaner, but I cannot separate the state for ordering and the 
state for node storage in the nicest way because of single-inheritance, or at 
least I can't see how to do that. (Suggestions welcome!)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request: JENA-1083: Factoring tuple ordering into TupleM...

[ajs6f]

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/120#issuecomment-169393952
  
Oops! Adding a last commit to keep all the ordering machinery more 
centralized.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

GitHub user ajs6f opened a pull request:

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

JENA-1083: Factoring tuple ordering into TupleMap



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

$ git pull https://github.com/ajs6f/jena JENA-1083

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

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


commit bcdb5aa2c304af0d71cb37fab80edbf80568a70b
Author: ajs6f 
Date:   2016-01-06T16:15:35Z

Factoring tuple ordering into TupleMap




> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1083: Factoring tuple ordering into TupleM...

[ajs6f]

GitHub user ajs6f opened a pull request:

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

JENA-1083: Factoring tuple ordering into TupleMap



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

$ git pull https://github.com/ajs6f/jena JENA-1083

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

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


commit bcdb5aa2c304af0d71cb37fab80edbf80568a70b
Author: ajs6f 
Date:   2016-01-06T16:15:35Z

Factoring tuple ordering into TupleMap




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[A. Soroka (JIRA)]

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

A. Soroka commented on JENA-1083:
-

[~andy.seaborne], can you assign this to me so I can open and "start progress" 
on it? Thanks!

> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1083) MInor refactoring in TupleTables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1083:
--

Github user ajs6f commented on the pull request:

https://github.com/apache/jena/pull/120#issuecomment-169393952
  
Oops! Adding a last commit to keep all the ordering machinery more 
centralized.


> MInor refactoring in TupleTables
> 
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: A. Soroka
>Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes, 
> particularly PMapTripleTable and PMapQuadTable that will clarify their use. 
> Specifically, current impls of those abstract types have to override several 
> methods for adding, removing, and finding tuples. In fact, the only 
> information being added when those methods are overridden is conversion 
> between canonical and internal tuple ordering. This refactoring is to provide 
> methods that do that conversion and nothing else, which will make two methods 
> the most that any implementation of those abstract classes will have to 
> provide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1111) Use QueryTransformOps/UpdateTransformOps for remote execution

[Andy Seaborne (JIRA)]

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

Andy Seaborne updated JENA-:

Description: 
JENA-976 brought in a syntax-rewrite engine.

That could be used to provide pre-binding-like functionality for remote 
operations.


  was:
QueryExecutionFactory uses prebinding to process QuerySolution provided for 
execution. (This is built in to execution: query engines allow an initial 
binding) That does not work for remote execution.

JENA-976 brought in a syntax-rewrite engine.

That could be used to provide pre-binding-like functionality for remote 
operations.



> Use QueryTransformOps/UpdateTransformOps for remote execution
> -
>
> Key: JENA-
> URL: https://issues.apache.org/jira/browse/JENA-
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
>
> JENA-976 brought in a syntax-rewrite engine.
> That could be used to provide pre-binding-like functionality for remote 
> operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1111) Use QueryTransformOps/UpdateTransformOps for remote execution

[Andy Seaborne (JIRA)]

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

Andy Seaborne updated JENA-:

Description: 
QueryExecutionFactory uses prebinding to process QuerySolution provided for 
execution. (This is built in to execution: query engines allow an initial 
binding) That does not work for remote execution.

JENA-976 brought in a syntax-rewrite engine.

That could be used to provide pre-binding-like functionality for remote 
operations.


  was:
JENA-976 brought in a syntax-rewrite engine.

That could be used to provide pre-binding-like functionality for remote 
operations.



> Use QueryTransformOps/UpdateTransformOps for remote execution
> -
>
> Key: JENA-
> URL: https://issues.apache.org/jira/browse/JENA-
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
>
> QueryExecutionFactory uses prebinding to process QuerySolution provided for 
> execution. (This is built in to execution: query engines allow an initial 
> binding) That does not work for remote execution.
> JENA-976 brought in a syntax-rewrite engine.
> That could be used to provide pre-binding-like functionality for remote 
> operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1111) Use QueryTransformOps/UpdateTransformOps for remote execution

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-:
-

It is also worth considering whether this ought to be the local execution 
mechanism as well.  The semantics are not identical in the presence of nested 
selects but it does look like more usual cases are covered.

Maybe then {{QueryExecutionFactory.create( QuerySolution)}} can be 
deprecated/removed (this will take several release cycles - it is long-time API 
operations).


> Use QueryTransformOps/UpdateTransformOps for remote execution
> -
>
> Key: JENA-
> URL: https://issues.apache.org/jira/browse/JENA-
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Minor
>
> QueryExecutionFactory uses prebinding to process QuerySolution provided for 
> execution. (This is built in to execution: query engines allow an initial 
> binding) That does not work for remote execution.
> JENA-976 brought in a syntax-rewrite engine.
> That could be used to provide pre-binding-like functionality for remote 
> operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: 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_r48998941
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -100,6 +100,38 @@ import org.apache.jena.sparql.core.Quad ;
 public class CLASS extends PARSERBASE
 {
 boolean allowAggregatesInExpressions = false ;
+
+public static void main(String args[]) {
+while (true) {
--- End diff --

New `CLASS` don't appear very often so this could be in a java source file 
for each language

In fact, it only needs to work for language ARQ which is a superset of 
SPARQL 1.1 

Also - have you seen the command `arq.qparse`? It reads in a query and 
prints it out (and performs internal checks on `.equals`, `.hashcode`, output 
sameas input and the algebra generated.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

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_r48998941
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -100,6 +100,38 @@ import org.apache.jena.sparql.core.Quad ;
 public class CLASS extends PARSERBASE
 {
 boolean allowAggregatesInExpressions = false ;
+
+public static void main(String args[]) {
+while (true) {
--- End diff --

New `CLASS` don't appear very often so this could be in a java source file 
for each language

In fact, it only needs to work for language ARQ which is a superset of 
SPARQL 1.1 

Also - have you seen the command `arq.qparse`? It reads in a query and 
prints it out (and performs internal checks on `.equals`, `.hashcode`, output 
sameas input and the algebra generated.


> 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
(v6.3.4#6332)

[GitHub] jena pull request: 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_r48999309
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -100,6 +100,38 @@ import org.apache.jena.sparql.core.Quad ;
 public class CLASS extends PARSERBASE
--- End diff --

tokens.txt is used to produce HTML - hence the additional syntax to 
indicate inline vs a token rule for each definition.

It is safer to hand edit for minor changes because you risk loosing the 
additional edits alreayd made.

(If running jj2tokens, send to a temporary file and pick out the new bits 
and edit in manually)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena pull request: 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_r49002105
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -327,6 +359,35 @@ void AskQuery() : {}
   SolutionModifier()
 }
 
+void JsonQuery() : {}
+{
+  JsonClause()
+  ( DatasetClause() )*
+  WhereClause()
+  SolutionModifier()
+}
+
+void JsonClause() : { Object o ; String s ; }
+{
+   { getQuery().setQueryJsonType() ; }
+  
+  s = String() < PNAME_NS >
+  (
--- End diff --

Yes - javacc will tokenize to PNAME_NS.  These is no COLON and if there 
were, theer would be other problems.

I have a devious idea!

Use the  PNAME_NS and follow with a java fragment that does additional 
checking:
```
   t = 
   { 
   if ( t.image is not exactly a ":" )
  throwParseException("message",  t.beginLine, t.beginColumn)
   }
```
This then restricts the legal token and means you won't to have to play 
complicated games with javacc to switch to a different token set (if that is 
even possible due to lookahead of characters).



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

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_r49002105
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -327,6 +359,35 @@ void AskQuery() : {}
   SolutionModifier()
 }
 
+void JsonQuery() : {}
+{
+  JsonClause()
+  ( DatasetClause() )*
+  WhereClause()
+  SolutionModifier()
+}
+
+void JsonClause() : { Object o ; String s ; }
+{
+   { getQuery().setQueryJsonType() ; }
+  
+  s = String() < PNAME_NS >
+  (
--- End diff --

Yes - javacc will tokenize to PNAME_NS.  These is no COLON and if there 
were, theer would be other problems.

I have a devious idea!

Use the  PNAME_NS and follow with a java fragment that does additional 
checking:
```
   t = 
   { 
   if ( t.image is not exactly a ":" )
  throwParseException("message",  t.beginLine, t.beginColumn)
   }
```
This then restricts the legal token and means you won't to have to play 
complicated games with javacc to switch to a different token set (if that is 
even possible due to lookahead of characters).



> 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
(v6.3.4#6332)

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

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_r49003225
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/lang/sparql_11/SPARQLParser11Constants.java
 ---
@@ -431,6 +433,7 @@
 "\"select\"",
 "\"distinct\"",
 "\"reduced\"",
+"\"json\"",
--- End diff --

This is a generated file - Put inside a `#ifdef ARQ ... #endif` in 
master.jj.


> 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
(v6.3.4#6332)

[GitHub] jena pull request: 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_r49003225
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/lang/sparql_11/SPARQLParser11Constants.java
 ---
@@ -431,6 +433,7 @@
 "\"select\"",
 "\"distinct\"",
 "\"reduced\"",
+"\"json\"",
--- End diff --

This is a generated file - Put inside a `#ifdef ARQ ... #endif` in 
master.jj.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---