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

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_r182390129
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -326,6 +361,46 @@ void AskQuery() : {}
   SolutionModifier()
 }
 
+#ifdef ARQ
+void JsonQuery() : {}
+{
+  JsonClause()
+  ( DatasetClause() )*
+  WhereClause()
+  SolutionModifier()
+}
+
+void JsonClause() : { Object o ; String s ; Token t; }
+{
+   { getQuery().setQueryJsonType() ; }
+  
+  s = String()
+  // PNAME_NS would eval true before COLON (default namescape) so we make 
sure we got what we were expecting
+  t = < PNAME_NS > {
+if ( ! t.image.equals(":") )
+  throwParseException("Prefix name expression not legal at this point 
: "+t.image, t.beginLine, t.beginColumn) ;
+  }
+  (
+o = Var() { getQuery().addResultVar((Var) o) ; 
getQuery().addJsonMapping(s, o) ; }
+  | o = String() { getQuery().addJsonMapping(s, o) ; }
+  | o = Number() { getQuery().addJsonMapping(s, o) ; }
+  )
+  (
+ s = String()
+t = < PNAME_NS > {
+  if ( ! t.image.equals(":") )
+throwParseException("Prefix name expression not legal at this 
point : "+t.image, t.beginLine, t.beginColumn) ;
+}
+(
+  o = Var() { getQuery().addResultVar((Var) o) ; 
getQuery().addJsonMapping(s, o) ; }
+| o = String() { getQuery().addJsonMapping(s, o) ; }
+| o = Number() { getQuery().addJsonMapping(s, o) ; }
+)
--- End diff --

Good idea! Using your TestJsonEval.java as base, and doing a quick change 
in the master.jj and grammars, to support it.


> 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_r182392871
  
--- 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 {");
--- End diff --

>JSON { "s": "FOO" } becomes JSON { "s": FOO }

Shouldn't it be

```
JSON { "s": "FOO" } becomes JSON { "s": "FOO" } // last FOO still with 
double quotes / a string?
```


---

[jira] [Commented] (JENA-1525) Add to for each jar module.

[ASF subversion and git services (JIRA)]

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

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

Commit 58a942b24d35e245841a1007efb70e4b308e89be in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=58a942b ]

JENA-1525: Default module name o.a.j.jena-dboe; own name for TDB2


> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




--
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_r182390129
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -326,6 +361,46 @@ void AskQuery() : {}
   SolutionModifier()
 }
 
+#ifdef ARQ
+void JsonQuery() : {}
+{
+  JsonClause()
+  ( DatasetClause() )*
+  WhereClause()
+  SolutionModifier()
+}
+
+void JsonClause() : { Object o ; String s ; Token t; }
+{
+   { getQuery().setQueryJsonType() ; }
+  
+  s = String()
+  // PNAME_NS would eval true before COLON (default namescape) so we make 
sure we got what we were expecting
+  t = < PNAME_NS > {
+if ( ! t.image.equals(":") )
+  throwParseException("Prefix name expression not legal at this point 
: "+t.image, t.beginLine, t.beginColumn) ;
+  }
+  (
+o = Var() { getQuery().addResultVar((Var) o) ; 
getQuery().addJsonMapping(s, o) ; }
+  | o = String() { getQuery().addJsonMapping(s, o) ; }
+  | o = Number() { getQuery().addJsonMapping(s, o) ; }
+  )
+  (
+ s = String()
+t = < PNAME_NS > {
+  if ( ! t.image.equals(":") )
+throwParseException("Prefix name expression not legal at this 
point : "+t.image, t.beginLine, t.beginColumn) ;
+}
+(
+  o = Var() { getQuery().addResultVar((Var) o) ; 
getQuery().addJsonMapping(s, o) ; }
+| o = String() { getQuery().addJsonMapping(s, o) ; }
+| o = Number() { getQuery().addJsonMapping(s, o) ; }
+)
--- End diff --

Good idea! Using your TestJsonEval.java as base, and doing a quick change 
in the master.jj and grammars, to support it.


---

[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_r182394976
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -2176,6 +2251,19 @@ String String() : { Token t ; String lex ; }
 }
 }
 
+#ifdef ARQ
+Number Number() : { Token t ; Number number ; }
+{
+  (
+t = < INTEGER > { number = integerValue(t.image) ; }
+  | t = < DECIMAL > { number = doubleValue(t.image) ; }
--- End diff --

Oh! It was by accident that it got fixed I think?

I copied parts of the `SelectClause()` to `JsonClause()`. More 
especifically, the Select had:

```
  // Expressions without ()
  ( LOOKAHEAD(2)
expr = BuiltInCall(){ getQuery().addResultVar((Var)null, 
expr) ; }
  | expr = FunctionCall()   { getQuery().addResultVar((Var)null, 
expr) ; }
  | n = RDFLiteral(){ getQuery().addResultVar((Var)null, 
NodeValue.makeNode(n)) ; }
  | n = NumericLiteral(){ getQuery().addResultVar((Var)null, 
NodeValue.makeNode(n)) ; }
  | n = BooleanLiteral(){ getQuery().addResultVar((Var)null, 
NodeValue.makeNode(n)) ; }
```

Which became the following for the JSON counterpart:

```
o = Var() { getQuery().addResultVar((Var)o) ; 
getQuery().addJsonMapping(s, o) ; }
  | o = RDFLiteral() { getQuery().addResultVar(s, NodeValue.makeNode(o)) ; 
getQuery().addJsonMapping(s, o) ; }
  | o = NumericLiteral() { getQuery().addResultVar(s, 
NodeValue.makeNode(o)) ; getQuery().addJsonMapping(s, o) ; }
  | o = BooleanLiteral() { getQuery().addResultVar(s, 
NodeValue.makeNode(o)) ; getQuery().addJsonMapping(s, o) ; }
```

More or less the same. But we have the Var (i.e. for cases like `"title" : 
?title`), and then I did not include the expressions (hence the lookahead 
removed).

Does it make sense @afs ? If so, we can actually remove the `Number()` and 
this whole #if ARQ block. And I believe the code is doing more or less what you 
suggested?

Thanks!
Bruno


---

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

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_r182394976
  
--- Diff: jena-arq/Grammar/master.jj ---
@@ -2176,6 +2251,19 @@ String String() : { Token t ; String lex ; }
 }
 }
 
+#ifdef ARQ
+Number Number() : { Token t ; Number number ; }
+{
+  (
+t = < INTEGER > { number = integerValue(t.image) ; }
+  | t = < DECIMAL > { number = doubleValue(t.image) ; }
--- End diff --

Oh! It was by accident that it got fixed I think?

I copied parts of the `SelectClause()` to `JsonClause()`. More 
especifically, the Select had:

```
  // Expressions without ()
  ( LOOKAHEAD(2)
expr = BuiltInCall(){ getQuery().addResultVar((Var)null, 
expr) ; }
  | expr = FunctionCall()   { getQuery().addResultVar((Var)null, 
expr) ; }
  | n = RDFLiteral(){ getQuery().addResultVar((Var)null, 
NodeValue.makeNode(n)) ; }
  | n = NumericLiteral(){ getQuery().addResultVar((Var)null, 
NodeValue.makeNode(n)) ; }
  | n = BooleanLiteral(){ getQuery().addResultVar((Var)null, 
NodeValue.makeNode(n)) ; }
```

Which became the following for the JSON counterpart:

```
o = Var() { getQuery().addResultVar((Var)o) ; 
getQuery().addJsonMapping(s, o) ; }
  | o = RDFLiteral() { getQuery().addResultVar(s, NodeValue.makeNode(o)) ; 
getQuery().addJsonMapping(s, o) ; }
  | o = NumericLiteral() { getQuery().addResultVar(s, 
NodeValue.makeNode(o)) ; getQuery().addJsonMapping(s, o) ; }
  | o = BooleanLiteral() { getQuery().addResultVar(s, 
NodeValue.makeNode(o)) ; getQuery().addJsonMapping(s, o) ; }
```

More or less the same. But we have the Var (i.e. for cases like `"title" : 
?title`), and then I did not include the expressions (hence the lookahead 
removed).

Does it make sense @afs ? If so, we can actually remove the `Number()` and 
this whole #if ARQ block. And I believe the code is doing more or less what you 
suggested?

Thanks!
Bruno


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

ASF GitHub Bot commented on JENA-632:
-

Github user kinow commented on the issue:

https://github.com/apache/jena/pull/114
  
Rebase'd against master. Added `TestJsonEval.java`, with a couple more 
tests. Then understood why the projected variables were not working.

Updated the grammar to call the method that populates the `projectedVars` 
collection. Now queries like `JSON { 'F' : 'string' } WHERE { }` resolve to `[ 
{ 'F' : 'string' } ]`.

Still need to work around the other comment about `Double`s.


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

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_r182392871
  
--- 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 {");
--- End diff --

>JSON { "s": "FOO" } becomes JSON { "s": FOO }

Shouldn't it be

```
JSON { "s": "FOO" } becomes JSON { "s": "FOO" } // last FOO still with 
double quotes / a string?
```


> 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
  
Rebase'd against master. Added `TestJsonEval.java`, with a couple more 
tests. Then understood why the projected variables were not working.

Updated the grammar to call the method that populates the `projectedVars` 
collection. Now queries like `JSON { 'F' : 'string' } WHERE { }` resolve to `[ 
{ 'F' : 'string' } ]`.

Still need to work around the other comment about `Double`s.


---

[jira] [Commented] (JENA-1525) Add to for each jar module.

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1525:
-

Also done, by following the same pattern:

* jena-elephas
* jena-jdbc
* jena-permissions
* jena-sdb
* jena-fuseki1
* jena-shade-guava (configure the shader)
* jena-iri

which just leaves jena-fuseki2. That needs some thinking about because it is 
not a simply single module, but has library jars, a war file, and 
combined-jars-with-dependencies.

> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

[jira] [Commented] (JENA-1525) Add to for each jar module.

[ASF subversion and git services (JIRA)]

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

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

Commit 928e70ff11c96feb2096adbdf49ebb3fa194d11d in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=928e70f ]

JENA-1525: More Automatic-Module-Name


> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

[jira] [Commented] (JENA-1525) Add to for each jar module.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1525:
--

Github user asfgit closed the pull request at:

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


> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

[jira] [Commented] (JENA-1525) Add to for each jar module.

[ASF subversion and git services (JIRA)]

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

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

Commit f5cd5b0d1a6c4ea6b7cb254dd458987bb2a52141 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=f5cd5b0 ]

JENA-1525: Merge commit 'refs/pull/400/head' of https://github.com/apache/jena

This closes #400.


> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

[jira] [Commented] (JENA-1525) Add to for each jar module.

[ASF subversion and git services (JIRA)]

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

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

Commit ea336dff9364c8928b81f960b86843b4f8e7 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=ea336df ]

JENA-1525: Automatic module name for jena-iri


> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

[GitHub] jena pull request #400: [JENA-1525] Add to

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (JENA-1525) Add to for each jar module.

[ASF subversion and git services (JIRA)]

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

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

Commit 188e00e3be792e71e4839d5db269fbde71468c4c in jena's branch 
refs/heads/master from [~christopher-johnson]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=188e00e ]

[JENA-1525] Add  to  for each jar module


> Add  to  for each jar module.
> -
>
> Key: JENA-1525
> URL: https://issues.apache.org/jira/browse/JENA-1525
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Priority: Major
>




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

Re: Java9 modules

[Andy Seaborne]

Christopher Johnson has helped a lot with getting Jena more Java9 ready. 
This time - setting the Automatic-Module-Name in the jar manifest.


We also have a split package (org.apache.jena.system) across jena-core 
and jena-arq (JENA-1424 to sort that out).


JENA-1525 / PR#400 adds automatic module names to the jars.

Given the pattern, I've extended that to all modules (I can't test this 
unfortunately but at least it's the framework)


* jena-permissions, jena-iri and jena-sdb also done.

Example:
https://github.com/apache/jena/commit/ea336dff9364c8928b81f960b86843b4f8e7

* jena-dboe is a module with jena-tdb2 a separate module

* jena-elephas, jena-jdbc

If the parent POM has the automatic module setting, all the jars get the 
same module which, with information from Christopher,makes them the same 
module.  Rob - I hope that's the right thing to do, change it if not. 
The module name is org.apache.jena.elephas, rather than 
org.apache.jena.hadoop (the root package); a random choice on my part.



Remaining: fuseki2, which has several bits and pieces and I'm out of 
time today.


Andy

[GitHub] jena pull request #394: JENA-1519: OpWalkerVisitor with custom operators

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (JENA-1519) OpWalkerVisitor should interact better with custom operators

[ASF subversion and git services (JIRA)]

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

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

Commit 1af87896dc9e6803878769f5d9eef2a5578b1de7 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=1af8789 ]

JENA-1519: Move decision about effectiveOp into walker.


> OpWalkerVisitor should interact better with custom operators
> 
>
> Key: JENA-1519
> URL: https://issues.apache.org/jira/browse/JENA-1519
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.



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

[jira] [Commented] (JENA-1519) OpWalkerVisitor should interact better with custom operators

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1519:
--

Github user asfgit closed the pull request at:

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


> OpWalkerVisitor should interact better with custom operators
> 
>
> Key: JENA-1519
> URL: https://issues.apache.org/jira/browse/JENA-1519
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.



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

[jira] [Commented] (JENA-1519) OpWalkerVisitor should interact better with custom operators

[ASF subversion and git services (JIRA)]

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

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

Commit 2a5577725073d04671cec0359f9597b54b1d1efd in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=2a55777 ]

JENA-1519: Merge commit 'refs/pull/394/head' of https://github.com/apache/jena

This closes #394.


> OpWalkerVisitor should interact better with custom operators
> 
>
> Key: JENA-1519
> URL: https://issues.apache.org/jira/browse/JENA-1519
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Priority: Major
>
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.



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

[jira] [Resolved] (JENA-1519) OpWalkerVisitor should interact better with custom operators

[Andy Seaborne (JIRA)]

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

Andy Seaborne resolved JENA-1519.
-
   Resolution: Fixed
 Assignee: Andy Seaborne
Fix Version/s: Jena 3.8.0

PR merged, thank you very much.

> OpWalkerVisitor should interact better with custom operators
> 
>
> Key: JENA-1519
> URL: https://issues.apache.org/jira/browse/JENA-1519
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.6.0
>Reporter: Jeremy Coulon
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.8.0
>
>
> When visiting an OpExt, current implementation of OpWalkerVisitor is just 
> calling the visitor on opExt.effectiveOp().
> However if OpExt is replacing a sub-tree of the algebra instead of a single 
> leaf node, the sub-tree is ignored by walker.
> I found this bug when trying to execute a query with a MINUS operator with 
> either side of the operator being replaced by an custom operator.
> For example the following query is not working, if I transform both side of 
> MINUS with a custom operator:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (bgp (triple ?animal rdf:type ex:Animal))}}
> {{    (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
> {{      (bgp (triple ?animal rdf:type ?type)}}
> which I transform into:
> {{(project (?animal)}}
> {{  (minus}}
> {{    (op-ext )}}
> {{    (op-ext )))}}
> The reason is that MINUS is calling OpVars.visibleVars() which does not walk 
> into the subop of the filter.



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

[jira] [Commented] (JENA-1527) GraphDB caches prefix map across transactions.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1527:
--

GitHub user afs opened a pull request:

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

JENA-1527: Create PrefixMap on each getPrefixMapping



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

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

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

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


commit ec67a007074b6beb42c72ae9a257e1876dd4a8b1
Author: Andy Seaborne 
Date:   2018-04-18T21:14:09Z

JENA-1527: Create PrefixMap on each getPrefixMapping




> GraphDB caches prefix map across transactions.
> --
>
> Key: JENA-1527
> URL: https://issues.apache.org/jira/browse/JENA-1527
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> The pattern below causes transaction errors ("BlockMgrJournal not active") 
> because the pmap is carried from trasnaction1 to transaction 2 in the 
> GraphBase cache (member "pm").
> {noformat}
> Graph g = dsg.getGraph(gn1);
> Txn.executeWrite(dsg, ()->{
> // Get, do not use. ** GraphBase caches **
> PrefixMapping pmap = g.getPrefixMapping();
> });
> Txn.executeWrite(dsg, ()-> {
> PrefixMapping pmap = g.getPrefixMapping();
> pmap.setNsPrefix("x0", "http:/example/x0#");
> });
> {noformat}



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

[jira] [Updated] (JENA-1527) GraphTDB caches prefix map across transactions.

[Andy Seaborne (JIRA)]

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

Andy Seaborne updated JENA-1527:

Summary: GraphTDB caches prefix map across transactions.  (was: GraphDB 
caches prefix map across transactions.)

> GraphTDB caches prefix map across transactions.
> ---
>
> Key: JENA-1527
> URL: https://issues.apache.org/jira/browse/JENA-1527
> Project: Apache Jena
>  Issue Type: Bug
>  Components: TDB
>Affects Versions: Jena 3.7.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
>
> The pattern below causes transaction errors ("BlockMgrJournal not active") 
> because the pmap is carried from trasnaction1 to transaction 2 in the 
> GraphBase cache (member "pm").
> {noformat}
> Graph g = dsg.getGraph(gn1);
> Txn.executeWrite(dsg, ()->{
> // Get, do not use. ** GraphBase caches **
> PrefixMapping pmap = g.getPrefixMapping();
> });
> Txn.executeWrite(dsg, ()-> {
> PrefixMapping pmap = g.getPrefixMapping();
> pmap.setNsPrefix("x0", "http:/example/x0#");
> });
> {noformat}



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

[GitHub] jena pull request #402: JENA-1527: Create PrefixMap on each getPrefixMapping

[afs]

GitHub user afs opened a pull request:

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

JENA-1527: Create PrefixMap on each getPrefixMapping



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

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

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

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


commit ec67a007074b6beb42c72ae9a257e1876dd4a8b1
Author: Andy Seaborne 
Date:   2018-04-18T21:14:09Z

JENA-1527: Create PrefixMap on each getPrefixMapping




---

Re: Dataset.getUnionModel()

[Adam Jacobs]

Hi Andy,

We are using the general dataset.
Our use case is simply that we are taking quads in from clients, which may or 
may not include a default graph.
We use the union model for several things, but one example is SHACL validation. 
So we always need to remember to include the default graph into the union model.
Currently, I've subclassed the DatasetImpl to override the unionModel() method; 
but it sounds like we may be an edge case.

Thanks,
-Adam

From: Andy Seaborne 
Sent: Saturday, April 14, 2018 5:01 PM
To: dev@jena.apache.org
Subject: Re: Dataset.getUnionModel()

Hi Adam,

Yes, the union model is the graph union of the named graphs and does not
include the default graph. This choice is intentional and is driven by
the SPARQL side of things.

It's a useful way to have manageability of the data by using the SPARQL
Graph Store Protocol to PUT and POST graphs that together make the
default graph to be queried. This matches the behaviour some other
triple stores.

Which kind of dataset are you using?

For the general dataset that can include any models, a graph can be
added twice so the default graph can be added as named graph as well and
so included in the union.

What is your application usage that naturally wanted the default model
to be included?

 Andy

On 14/04/18 21:00, Adam Jacobs wrote:
> Dataset.getUnionModel() excludes the default graph.
> Would it be appropriate to include the default graph in this method, or to 
> add an additional unioning method to the Dataset interface which includes the 
> default graph?
> It seems like an oversight, but maybe there was a reason for excluding it?
>