[jira] [Commented] (JENA-1313) Language-specific collation in ARQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1313:
--

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

https://github.com/apache/jena/pull/237#discussion_r116373375
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -774,19 +772,10 @@ private static int compare(NodeValue nv1, NodeValue 
nv2, boolean sortOrderingCom
 }
 case VSPACE_SORTKEY :
 {
-int cmp = 0;
-String c1 = nv1.getCollation();
-String c2 = nv2.getCollation();
-if (c1 != null && c2 != null && c1.equals(c2)) {
-// locales are parsed. Here we could think about 
caching if necessary
-Locale desiredLocale = Locale.forLanguageTag(c1);
-// collators are already stored in a concurrent map by 
the JVM, with >
-Collator collator = 
Collator.getInstance(desiredLocale);
-cmp = collator.compare(nv1.getString(), 
nv2.getString());
-} else {
-cmp = XSDFuncOp.compareString(nv1, nv2) ;
+if (!(nv1 instanceof NodeValueSortKey) || !(nv2 instanceof 
NodeValueSortKey)) {
+raise(new ExprNotComparableException("Can't compare 
(not node value sort keys) "+nv1+" and "+nv2)) ;
--- End diff --

Agree, right now there is no way of that happening, as the value space for 
sort keys is returned only when both node values are `NodeSortKey`s. Added more 
to prevent bugs in case anyone ever changed the function returning the value 
space.

Should we remove it?


> Language-specific collation in ARQ
> --
>
> Key: JENA-1313
> URL: https://issues.apache.org/jira/browse/JENA-1313
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.2.0
>Reporter: Osma Suominen
>
> As [discussed|http://markmail.org/message/v2bvsnsza5ksl2cv] on the users 
> mailing list in October 2016, I would like to change ARQ collation of literal 
> values to be language-aware and respect language-specific collation rules.
> This would probably involve changing at least the 
> [NodeUtils.compareLiteralsBySyntax|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/util/NodeUtils.java#L199]
>  method.
> It currently sorts by lexical value first, then by language tag. Since the 
> collation order needs to be stable across all possible literal values, I 
> think the safest way would be to sort by language tag first, then by lexical 
> value according to the collation rules for that language.
> But what about subtags like {{@en-US}} or {{@pt-BR}}? Can they have different 
> collation rules than the main language? It would be a bit strange if all 
> {{@en-US}} literals sorted after {{@en}} literals...
> It would be good to check how Dydra does this and possibly take the same 
> approach. See the message linked above for further backgound.
> I've been talking with [~kinow] about this and he may be interested in 
> implementing it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] jena pull request #237: JENA-1313: compare using a Collator when both litera...

[kinow]

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

https://github.com/apache/jena/pull/237#discussion_r116373375
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -774,19 +772,10 @@ private static int compare(NodeValue nv1, NodeValue 
nv2, boolean sortOrderingCom
 }
 case VSPACE_SORTKEY :
 {
-int cmp = 0;
-String c1 = nv1.getCollation();
-String c2 = nv2.getCollation();
-if (c1 != null && c2 != null && c1.equals(c2)) {
-// locales are parsed. Here we could think about 
caching if necessary
-Locale desiredLocale = Locale.forLanguageTag(c1);
-// collators are already stored in a concurrent map by 
the JVM, with >
-Collator collator = 
Collator.getInstance(desiredLocale);
-cmp = collator.compare(nv1.getString(), 
nv2.getString());
-} else {
-cmp = XSDFuncOp.compareString(nv1, nv2) ;
+if (!(nv1 instanceof NodeValueSortKey) || !(nv2 instanceof 
NodeValueSortKey)) {
+raise(new ExprNotComparableException("Can't compare 
(not node value sort keys) "+nv1+" and "+nv2)) ;
--- End diff --

Agree, right now there is no way of that happening, as the value space for 
sort keys is returned only when both node values are `NodeSortKey`s. Added more 
to prevent bugs in case anyone ever changed the function returning the value 
space.

Should we remove it?


---
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-1313) Language-specific collation in ARQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1313:
--

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

https://github.com/apache/jena/pull/237#discussion_r116365929
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -978,7 +967,6 @@ public boolean isDayTimeDuration()
 public boolean getBoolean() { raise(new 
ExprEvalTypeException("Not a boolean: "+this)) ; return false ; }
 public String  getString()  { raise(new 
ExprEvalTypeException("Not a string: "+this)) ; return null ; }
 public String  getLang(){ raise(new 
ExprEvalTypeException("Not a string: "+this)) ; return null ; }
-public String  getCollation()   { raise(new 
ExprEvalTypeException("Not a sort key: "+this)) ; return null ; }
 
--- End diff --

This would be the "value" of a NodeValueSortKey ... which is itself so 
NodeValueSortKey then the casts aren't needed in the comparision.


> Language-specific collation in ARQ
> --
>
> Key: JENA-1313
> URL: https://issues.apache.org/jira/browse/JENA-1313
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.2.0
>Reporter: Osma Suominen
>
> As [discussed|http://markmail.org/message/v2bvsnsza5ksl2cv] on the users 
> mailing list in October 2016, I would like to change ARQ collation of literal 
> values to be language-aware and respect language-specific collation rules.
> This would probably involve changing at least the 
> [NodeUtils.compareLiteralsBySyntax|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/util/NodeUtils.java#L199]
>  method.
> It currently sorts by lexical value first, then by language tag. Since the 
> collation order needs to be stable across all possible literal values, I 
> think the safest way would be to sort by language tag first, then by lexical 
> value according to the collation rules for that language.
> But what about subtags like {{@en-US}} or {{@pt-BR}}? Can they have different 
> collation rules than the main language? It would be a bit strange if all 
> {{@en-US}} literals sorted after {{@en}} literals...
> It would be good to check how Dydra does this and possibly take the same 
> approach. See the message linked above for further backgound.
> I've been talking with [~kinow] about this and he may be interested in 
> implementing it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] jena pull request #237: JENA-1313: compare using a Collator when both litera...

[afs]

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

https://github.com/apache/jena/pull/237#discussion_r116365929
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -978,7 +967,6 @@ public boolean isDayTimeDuration()
 public boolean getBoolean() { raise(new 
ExprEvalTypeException("Not a boolean: "+this)) ; return false ; }
 public String  getString()  { raise(new 
ExprEvalTypeException("Not a string: "+this)) ; return null ; }
 public String  getLang(){ raise(new 
ExprEvalTypeException("Not a string: "+this)) ; return null ; }
-public String  getCollation()   { raise(new 
ExprEvalTypeException("Not a sort key: "+this)) ; return null ; }
 
--- End diff --

This would be the "value" of a NodeValueSortKey ... which is itself so 
NodeValueSortKey then the casts aren't needed in the comparision.


---
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-1313) Language-specific collation in ARQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1313:
--

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

https://github.com/apache/jena/pull/237#discussion_r116365872
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -774,19 +772,10 @@ private static int compare(NodeValue nv1, NodeValue 
nv2, boolean sortOrderingCom
 }
 case VSPACE_SORTKEY :
 {
-int cmp = 0;
-String c1 = nv1.getCollation();
-String c2 = nv2.getCollation();
-if (c1 != null && c2 != null && c1.equals(c2)) {
-// locales are parsed. Here we could think about 
caching if necessary
-Locale desiredLocale = Locale.forLanguageTag(c1);
-// collators are already stored in a concurrent map by 
the JVM, with >
-Collator collator = 
Collator.getInstance(desiredLocale);
-cmp = collator.compare(nv1.getString(), 
nv2.getString());
-} else {
-cmp = XSDFuncOp.compareString(nv1, nv2) ;
+if (!(nv1 instanceof NodeValueSortKey) || !(nv2 instanceof 
NodeValueSortKey)) {
+raise(new ExprNotComparableException("Can't compare 
(not node value sort keys) "+nv1+" and "+nv2)) ;
--- End diff --

That shouldn't happen if the comparison is VALUE_SORTKEY


> Language-specific collation in ARQ
> --
>
> Key: JENA-1313
> URL: https://issues.apache.org/jira/browse/JENA-1313
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.2.0
>Reporter: Osma Suominen
>
> As [discussed|http://markmail.org/message/v2bvsnsza5ksl2cv] on the users 
> mailing list in October 2016, I would like to change ARQ collation of literal 
> values to be language-aware and respect language-specific collation rules.
> This would probably involve changing at least the 
> [NodeUtils.compareLiteralsBySyntax|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/util/NodeUtils.java#L199]
>  method.
> It currently sorts by lexical value first, then by language tag. Since the 
> collation order needs to be stable across all possible literal values, I 
> think the safest way would be to sort by language tag first, then by lexical 
> value according to the collation rules for that language.
> But what about subtags like {{@en-US}} or {{@pt-BR}}? Can they have different 
> collation rules than the main language? It would be a bit strange if all 
> {{@en-US}} literals sorted after {{@en}} literals...
> It would be good to check how Dydra does this and possibly take the same 
> approach. See the message linked above for further backgound.
> I've been talking with [~kinow] about this and he may be interested in 
> implementing it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] jena pull request #237: JENA-1313: compare using a Collator when both litera...

[afs]

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

https://github.com/apache/jena/pull/237#discussion_r116365872
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -774,19 +772,10 @@ private static int compare(NodeValue nv1, NodeValue 
nv2, boolean sortOrderingCom
 }
 case VSPACE_SORTKEY :
 {
-int cmp = 0;
-String c1 = nv1.getCollation();
-String c2 = nv2.getCollation();
-if (c1 != null && c2 != null && c1.equals(c2)) {
-// locales are parsed. Here we could think about 
caching if necessary
-Locale desiredLocale = Locale.forLanguageTag(c1);
-// collators are already stored in a concurrent map by 
the JVM, with >
-Collator collator = 
Collator.getInstance(desiredLocale);
-cmp = collator.compare(nv1.getString(), 
nv2.getString());
-} else {
-cmp = XSDFuncOp.compareString(nv1, nv2) ;
+if (!(nv1 instanceof NodeValueSortKey) || !(nv2 instanceof 
NodeValueSortKey)) {
+raise(new ExprNotComparableException("Can't compare 
(not node value sort keys) "+nv1+" and "+nv2)) ;
--- End diff --

That shouldn't happen if the comparison is VALUE_SORTKEY


---
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-1313) Language-specific collation in ARQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1313:
--

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

https://github.com/apache/jena/pull/237#discussion_r116365836
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/expr/nodevalue/NodeValueSortKey.java
 ---
@@ -0,0 +1,91 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.sparql.expr.nodevalue;
+
+import org.apache.jena.graph.Node;
+import org.apache.jena.graph.NodeFactory;
+import org.apache.jena.sparql.expr.NodeValue;
+import org.apache.jena.sparql.util.FmtUtils;
+
+/**
+ * A {@link NodeValue} that supports collation value for a string. This 
allows query values
+ * to be sorted following rules for a specific collation.
+ */
+public class NodeValueSortKey extends NodeValue {
+
+/**
+ * Node value text.
+ */
+private final String string;
+/**
+ * Node value collation language tag (e.g. fi, pt-BR, en, en-CA, etc).
+ */
+private final String collation;
+
+public NodeValueSortKey(final String string, final String collation) {
+this.string = string;
+this.collation = collation;
+}
+
+public NodeValueSortKey(final String string, final String collation, 
Node n) {
+super(n);
+this.string = string;
+this.collation = collation;
+}
+
+@Override
+public boolean isSortKey() {
+return Boolean.TRUE;
+}
+
+@Override
+public String getString() {
+return string;
+}
+
+@Override
+public String asString() {
+return string;
+}
+
+@Override
+public String getCollation() {
+return collation;
+}
+
+@Override
+protected Node makeNode() {
+return NodeFactory.createLiteral(string);
+}
+
--- End diff --

Marking final makes sense. There are some details in the way 
NodeValueSortKey does not follow the pattern of other NodeValues e.g. the 
"getXYZ" operations return its value (so getString isfor xsd:string to return 
their string value, getInteger on NodeValueInteger etc.



> Language-specific collation in ARQ
> --
>
> Key: JENA-1313
> URL: https://issues.apache.org/jira/browse/JENA-1313
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.2.0
>Reporter: Osma Suominen
>
> As [discussed|http://markmail.org/message/v2bvsnsza5ksl2cv] on the users 
> mailing list in October 2016, I would like to change ARQ collation of literal 
> values to be language-aware and respect language-specific collation rules.
> This would probably involve changing at least the 
> [NodeUtils.compareLiteralsBySyntax|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/util/NodeUtils.java#L199]
>  method.
> It currently sorts by lexical value first, then by language tag. Since the 
> collation order needs to be stable across all possible literal values, I 
> think the safest way would be to sort by language tag first, then by lexical 
> value according to the collation rules for that language.
> But what about subtags like {{@en-US}} or {{@pt-BR}}? Can they have different 
> collation rules than the main language? It would be a bit strange if all 
> {{@en-US}} literals sorted after {{@en}} literals...
> It would be good to check how Dydra does this and possibly take the same 
> approach. See the message linked above for further backgound.
> I've been talking with [~kinow] about this and he may be interested in 
> implementing it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JENA-1313) Language-specific collation in ARQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1313:
--

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

https://github.com/apache/jena/pull/237#discussion_r116365710
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -774,19 +772,10 @@ private static int compare(NodeValue nv1, NodeValue 
nv2, boolean sortOrderingCom
 }
 case VSPACE_SORTKEY :
 {
-int cmp = 0;
-String c1 = nv1.getCollation();
-String c2 = nv2.getCollation();
-if (c1 != null && c2 != null && c1.equals(c2)) {
-// locales are parsed. Here we could think about 
caching if necessary
-Locale desiredLocale = Locale.forLanguageTag(c1);
-// collators are already stored in a concurrent map by 
the JVM, with >
-Collator collator = 
Collator.getInstance(desiredLocale);
-cmp = collator.compare(nv1.getString(), 
nv2.getString());
-} else {
-cmp = XSDFuncOp.compareString(nv1, nv2) ;
+if (!(nv1 instanceof NodeValueSortKey) || !(nv2 instanceof 
NodeValueSortKey)) {
+raise(new ExprNotComparableException("Can't compare 
(not node value sort keys) "+nv1+" and "+nv2)) ;
 }
-return cmp;
+return ((NodeValueSortKey) 
nv1).compareTo((NodeValueSortKey) nv2);
 }
--- End diff --

Should that be `nv1.getSortKey()`?  All the NodeValues have downcast 
operations getXYZ().


> Language-specific collation in ARQ
> --
>
> Key: JENA-1313
> URL: https://issues.apache.org/jira/browse/JENA-1313
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.2.0
>Reporter: Osma Suominen
>
> As [discussed|http://markmail.org/message/v2bvsnsza5ksl2cv] on the users 
> mailing list in October 2016, I would like to change ARQ collation of literal 
> values to be language-aware and respect language-specific collation rules.
> This would probably involve changing at least the 
> [NodeUtils.compareLiteralsBySyntax|https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/util/NodeUtils.java#L199]
>  method.
> It currently sorts by lexical value first, then by language tag. Since the 
> collation order needs to be stable across all possible literal values, I 
> think the safest way would be to sort by language tag first, then by lexical 
> value according to the collation rules for that language.
> But what about subtags like {{@en-US}} or {{@pt-BR}}? Can they have different 
> collation rules than the main language? It would be a bit strange if all 
> {{@en-US}} literals sorted after {{@en}} literals...
> It would be good to check how Dydra does this and possibly take the same 
> approach. See the message linked above for further backgound.
> I've been talking with [~kinow] about this and he may be interested in 
> implementing it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] jena pull request #237: JENA-1313: compare using a Collator when both litera...

[afs]

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

https://github.com/apache/jena/pull/237#discussion_r116365710
  
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/expr/NodeValue.java 
---
@@ -774,19 +772,10 @@ private static int compare(NodeValue nv1, NodeValue 
nv2, boolean sortOrderingCom
 }
 case VSPACE_SORTKEY :
 {
-int cmp = 0;
-String c1 = nv1.getCollation();
-String c2 = nv2.getCollation();
-if (c1 != null && c2 != null && c1.equals(c2)) {
-// locales are parsed. Here we could think about 
caching if necessary
-Locale desiredLocale = Locale.forLanguageTag(c1);
-// collators are already stored in a concurrent map by 
the JVM, with >
-Collator collator = 
Collator.getInstance(desiredLocale);
-cmp = collator.compare(nv1.getString(), 
nv2.getString());
-} else {
-cmp = XSDFuncOp.compareString(nv1, nv2) ;
+if (!(nv1 instanceof NodeValueSortKey) || !(nv2 instanceof 
NodeValueSortKey)) {
+raise(new ExprNotComparableException("Can't compare 
(not node value sort keys) "+nv1+" and "+nv2)) ;
 }
-return cmp;
+return ((NodeValueSortKey) 
nv1).compareTo((NodeValueSortKey) nv2);
 }
--- End diff --

Should that be `nv1.getSortKey()`?  All the NodeValues have downcast 
operations getXYZ().


---
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 #237: JENA-1313: compare using a Collator when both litera...

[afs]

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

https://github.com/apache/jena/pull/237#discussion_r116365836
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/expr/nodevalue/NodeValueSortKey.java
 ---
@@ -0,0 +1,91 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jena.sparql.expr.nodevalue;
+
+import org.apache.jena.graph.Node;
+import org.apache.jena.graph.NodeFactory;
+import org.apache.jena.sparql.expr.NodeValue;
+import org.apache.jena.sparql.util.FmtUtils;
+
+/**
+ * A {@link NodeValue} that supports collation value for a string. This 
allows query values
+ * to be sorted following rules for a specific collation.
+ */
+public class NodeValueSortKey extends NodeValue {
+
+/**
+ * Node value text.
+ */
+private final String string;
+/**
+ * Node value collation language tag (e.g. fi, pt-BR, en, en-CA, etc).
+ */
+private final String collation;
+
+public NodeValueSortKey(final String string, final String collation) {
+this.string = string;
+this.collation = collation;
+}
+
+public NodeValueSortKey(final String string, final String collation, 
Node n) {
+super(n);
+this.string = string;
+this.collation = collation;
+}
+
+@Override
+public boolean isSortKey() {
+return Boolean.TRUE;
+}
+
+@Override
+public String getString() {
+return string;
+}
+
+@Override
+public String asString() {
+return string;
+}
+
+@Override
+public String getCollation() {
+return collation;
+}
+
+@Override
+protected Node makeNode() {
+return NodeFactory.createLiteral(string);
+}
+
--- End diff --

Marking final makes sense. There are some details in the way 
NodeValueSortKey does not follow the pattern of other NodeValues e.g. the 
"getXYZ" operations return its value (so getString isfor xsd:string to return 
their string value, getInteger on NodeValueInteger etc.



---
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 issue #233: Added mosaic and thrift packages to org.apache.jena.sparql....

[dick-twocows]

Github user dick-twocows commented on the issue:

https://github.com/apache/jena/pull/233
  
Here's for starters.
DatasetGaphThrift is a thrift based wrapper for an existing DatasetGaph. It 
includes a Java IFace and Server implementation and instructions on how to use 
another language to access the wrapped DSG. This allows a DSG to be accessed in 
another JVM. This is binary part.
DatasetGaphMosaic wraps multiple DSG and presents them as one DSG. Useful 
when the wrapped DSG is a DSG thrift. It will apply optimistic locking and 
wraps the transaction with a try mechanism. Effectively MRMW with no contention 
unless writes are to the same DSG. This is clustering part.
DatasetGaphMirage uses rules to auto magic quads based on the find methods. 
An example Ray is a folder which is mapped from between a urn: and file: schema 
and has the ability to load triples and quads to fulfill the find methods 
calls. This is dynamic part.
Thrift I think is a candidate for core. Mosaic and Mirage I'm thinking more 
of an associated pom...
Dick
 Original message From: Andy Seaborne 
 Date: 13/05/2017  19:19  (GMT+00:00) To: apache/jena 
 Cc: Dick Murray , Mention 
 Subject: Re: [apache/jena] Added mosaic and thrift 
packages to org.apache.jena.sparql.core. (#233) 
What would a good start is an overview of what this covers.
I'm looking for 2 things : what informs the core framework and what are new 
capabilities for systems/modules.
This started with our discussions about binaries and binary protocols so 
that would be a good starting place.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


  
  





{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/apache/jena","title":"apache/jena","subtitle":"GitHub
 
repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
 in 
GitHub","url":"https://github.com/apache/jena"}},"updates":{"snippets":[{"icon":"PERSON","message":"@afs
 in #233: What would a good start is an overview of what this 
covers.\r\n\r\nI'm looking for 2 things : what informs the core framework and 
what are new capabilities for systems/modules.\r\n\r\nThis started with our 
discussions about binaries and binary protocols so that would be a good 
starting place.\r\n"}],"action":{"name":"View Pull 
Request","url":"https://github.com/apache/jena/pull/233#issuecomment-301265464"}}}


---
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 issue #233: Added mosaic and thrift packages to org.apache.jena.sparql....

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/233
  
What would a good start is an overview of what this covers.

I'm looking for 2 things : what informs the core framework and what are new 
capabilities for systems/modules.

This started with our discussions about binaries and binary protocols so 
that would be a good starting place.



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

Re: Evolution and legacy modules

[ajs6f]

I agree that Any23 could be a good home for it, and better than Commons RDF, which seems to be more focused on the basic RDF API, and I also agree that we 
should keep an ongoing policy of trying to work with Commons RDF when possible. I don't think any development we have in the immediate future is of great impact 
there, but as we evolve Jena's API it would be nice to do it in a way that supports Commons RDF's goal of interop, when that is practical for us.


---
A. Soroka

Claude Warren wrote on 5/13/17 6:09 AM:

Another possible home would be the any23 project.

I have some CSV reader code that handle arbitrary formats and column
names.  Not sure I want to spend the time to merge it into CSV and support
it though.



On Fri, May 12, 2017 at 11:17 AM, Andy Seaborne  wrote:




On 12/05/17 07:30, Claude Warren wrote:


+1  After some thought I agree too.

== Question on the CSV stuff and perhaps a "policy" idea. ==

Does the CSV conceptually just do IO into the graph?



The CSV code reads data, not write it.  It uses a fixed and simple RDF
vocabulary.



How closely are we aligned with RDF-Commons?

Does it make sense that we urge (push is too strong a word) load/save of
non-standard format (like CSV) to RDF-Commons where it might benefit a
wider audience and have more development backing?

I guess the "policy" idea is to look for synergies with RDF-Commons and
act
accordingly.



The CSV code would fit well with working over the CommonsRDF API. IMO the
biggest value of CommonsRDF is common algorithms that can run on multiple
toolkits.

Howver, CommonsRDF does not seem like a place where there is more
development resources though.

Andy




Claude






On Thu, May 11, 2017 at 3:06 PM,  wrote:

I'm basically +1 to this. I wouldn't mind "setting a cron job" to do a

similar review every other or every three releases.

---
A. Soroka

Bruno P. Kinoshita wrote on 5/11/17 4:59 AM:

+1 to removing Fuseki1 now. And +1 for the legacy module definition and


expectations.
I'd be fine with jena-csv being removed, though I can see that being
useful for people who need to quickly ingest data into something like
Hadoop/Hive.
And jena-spatial and jena-text are modules that I plan to study someday,
just to have fun learning the ins and outs. May submit smaller commits
to
fix bits and pieces but not sure if could maintain the module.
CheersBruno

  From: Andy Seaborne 
 To: dev@jena.apache.org
 Sent: Thursday, 11 May 2017 8:19 AM
 Subject: Evolution and legacy modules

We need to do more than just add code to Jena; there needs to be a route
to removing code as well.

Starting with modules, there are some that are some that don't get the
same care and attention and without some level of maintenance, such
modules are dead weight to development.

A "legacy module"

* does not hold up a release
* may be removed from the build
  (so they get swept up in a release as source only)
* may be archived
  (taken out of the build and put elsewhere, such as a different repo)

The way for anyone to "unlegacy" is to give it care and attention.

Suggestions for legacy modules:

  jena-sdb
  jena-fuseki1
  jena-csv
  jena-maven-tools
  jena-spatial

Others?

I don't have any plans to remove jena-sdb and it is unlikely to get in
the way. TQ do not use it.

jena-csv interferes with RIOT as it has a pseudo RDF Syntax for CSV
which is simple and not standard (not CSVW).  Steps to untangle it are
in v3.3.0 and now we can make us of the pseudo RDF Syntax require
jena-csv and put it all there.


For Fuseki1, the next steps would be to remove it from the direct
mention:

* Remove explicit mention on the downloads page.
* Remove jena-fuseki1 binary from the dist/binaries/ area.
* Remove Fuseki1 from the javadoc on the website and the javadoc maker.

These can be done now, not at the next release - it's not releasing
anything.

Andy

[GitHub] jena issue #233: Added mosaic and thrift packages to org.apache.jena.sparql....

[dick-twocows]

Github user dick-twocows commented on the issue:

https://github.com/apache/jena/pull/233
  
Stalled to test 3.3.0 and get a customer release out...


Dick
 Original message From: "A. Soroka" 
 Date: 13/05/2017  13:20  (GMT+00:00) To: apache/jena 
 Cc: Dick Murray , Mention 
 Subject: Re: [apache/jena] Added mosaic and thrift 
packages to org.apache.jena.sparql.core. (#233) 
Okay, cool! Just give a yell when you want more eyes on it. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


  
  





{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/apache/jena","title":"apache/jena","subtitle":"GitHub
 
repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
 in 
GitHub","url":"https://github.com/apache/jena"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ajs6f
 in #233: Okay, cool! Just give a yell when you want more eyes on it. 
Thanks!"}],"action":{"name":"View Pull 
Request","url":"https://github.com/apache/jena/pull/233#issuecomment-301244745"}}}


---
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 issue #233: Added mosaic and thrift packages to org.apache.jena.sparql....

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/233
  
Okay, cool! Just give a yell when you want more eyes on it. Thanks!


---
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 issue #233: Added mosaic and thrift packages to org.apache.jena.sparql....

[dick-twocows]

Github user dick-twocows commented on the issue:

https://github.com/apache/jena/pull/233
  
There's some more to commit and I want the tests in as well...


Dick
 Original message From: "A. Soroka" 
 Date: 13/05/2017  13:06  (GMT+00:00) To: apache/jena 
 Cc: Dick Murray , Mention 
 Subject: Re: [apache/jena] Added mosaic and thrift 
packages to org.apache.jena.sparql.core. (#233) 
Hey, @dick-twocows -- just checking in on this. Are you still adding more 
commits or is it time to move on to in-dept review? Thanks again for this 
contribution!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


  
  





{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/apache/jena","title":"apache/jena","subtitle":"GitHub
 
repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
 in 
GitHub","url":"https://github.com/apache/jena"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ajs6f
 in #233: Hey, @dick-twocows -- just checking in on this. Are you still adding 
more commits or is it time to move on to in-dept review? Thanks again for this 
contribution!"}],"action":{"name":"View Pull 
Request","url":"https://github.com/apache/jena/pull/233#issuecomment-301244095"}}}


---
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 issue #233: Added mosaic and thrift packages to org.apache.jena.sparql....

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/233
  
Hey, @dick-twocows -- just checking in on this. Are you still adding more 
commits or is it time to move on to in-dept review? Thanks again for this 
contribution!


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

Re: Evolution and legacy modules

[Claude Warren]

Another possible home would be the any23 project.

I have some CSV reader code that handle arbitrary formats and column
names.  Not sure I want to spend the time to merge it into CSV and support
it though.



On Fri, May 12, 2017 at 11:17 AM, Andy Seaborne  wrote:

>
>
> On 12/05/17 07:30, Claude Warren wrote:
>
>> +1  After some thought I agree too.
>>
>> == Question on the CSV stuff and perhaps a "policy" idea. ==
>>
>> Does the CSV conceptually just do IO into the graph?
>>
>
> The CSV code reads data, not write it.  It uses a fixed and simple RDF
> vocabulary.
>
>
>> How closely are we aligned with RDF-Commons?
>>
>> Does it make sense that we urge (push is too strong a word) load/save of
>> non-standard format (like CSV) to RDF-Commons where it might benefit a
>> wider audience and have more development backing?
>>
>> I guess the "policy" idea is to look for synergies with RDF-Commons and
>> act
>> accordingly.
>>
>
> The CSV code would fit well with working over the CommonsRDF API. IMO the
> biggest value of CommonsRDF is common algorithms that can run on multiple
> toolkits.
>
> Howver, CommonsRDF does not seem like a place where there is more
> development resources though.
>
> Andy
>
>
>
>> Claude
>>
>>
>>
>>
>>
>>
>> On Thu, May 11, 2017 at 3:06 PM,  wrote:
>>
>> I'm basically +1 to this. I wouldn't mind "setting a cron job" to do a
>>> similar review every other or every three releases.
>>>
>>> ---
>>> A. Soroka
>>>
>>> Bruno P. Kinoshita wrote on 5/11/17 4:59 AM:
>>>
>>> +1 to removing Fuseki1 now. And +1 for the legacy module definition and
>>>
 expectations.
 I'd be fine with jena-csv being removed, though I can see that being
 useful for people who need to quickly ingest data into something like
 Hadoop/Hive.
 And jena-spatial and jena-text are modules that I plan to study someday,
 just to have fun learning the ins and outs. May submit smaller commits
 to
 fix bits and pieces but not sure if could maintain the module.
 CheersBruno

   From: Andy Seaborne 
  To: dev@jena.apache.org
  Sent: Thursday, 11 May 2017 8:19 AM
  Subject: Evolution and legacy modules

 We need to do more than just add code to Jena; there needs to be a route
 to removing code as well.

 Starting with modules, there are some that are some that don't get the
 same care and attention and without some level of maintenance, such
 modules are dead weight to development.

 A "legacy module"

 * does not hold up a release
 * may be removed from the build
   (so they get swept up in a release as source only)
 * may be archived
   (taken out of the build and put elsewhere, such as a different repo)

 The way for anyone to "unlegacy" is to give it care and attention.

 Suggestions for legacy modules:

   jena-sdb
   jena-fuseki1
   jena-csv
   jena-maven-tools
   jena-spatial

 Others?

 I don't have any plans to remove jena-sdb and it is unlikely to get in
 the way. TQ do not use it.

 jena-csv interferes with RIOT as it has a pseudo RDF Syntax for CSV
 which is simple and not standard (not CSVW).  Steps to untangle it are
 in v3.3.0 and now we can make us of the pseudo RDF Syntax require
 jena-csv and put it all there.


 For Fuseki1, the next steps would be to remove it from the direct
 mention:

 * Remove explicit mention on the downloads page.
 * Remove jena-fuseki1 binary from the dist/binaries/ area.
 * Remove Fuseki1 from the javadoc on the website and the javadoc maker.

 These can be done now, not at the next release - it's not releasing
 anything.

 Andy







>>
>>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

[jira] [Resolved] (JENA-1046) Button "Add a SPARQL prefix" not visible in fuseki web interface

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita resolved JENA-1046.
--
   Resolution: Fixed
Fix Version/s: Jena 3.4.0

Fixed in 5bf38bbdc3fea6824984a4826bec82f211a609ba. Marking as Fixed.

> Button "Add a SPARQL prefix" not visible in fuseki web interface
> 
>
> Key: JENA-1046
> URL: https://issues.apache.org/jira/browse/JENA-1046
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.0
>Reporter: Gabriele Cornacchia
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 3.4.0
>
> Attachments: JENA-1046-after.png, JENA-1046-before.png, 
> JENA-1046-modal.png
>
>
> In fuseki web interface.
>  dataset.html page -> tab "query" -> section "PREFIXES"
> the button to add a new prefix
> "
> 
>  "
> is not visible.
> I tried with firefox 41.0.1 and Chrome 45.0.2454.101 m
> is it an expected behavior or an error?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JENA-1046) Button "Add a SPARQL prefix" not visible in fuseki web interface

[ASF subversion and git services (JIRA)]

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

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

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

JENA-1046 correct CSS classes for Add Prefix button


> Button "Add a SPARQL prefix" not visible in fuseki web interface
> 
>
> Key: JENA-1046
> URL: https://issues.apache.org/jira/browse/JENA-1046
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.0
>Reporter: Gabriele Cornacchia
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: Jena 3.4.0
>
> Attachments: JENA-1046-after.png, JENA-1046-before.png, 
> JENA-1046-modal.png
>
>
> In fuseki web interface.
>  dataset.html page -> tab "query" -> section "PREFIXES"
> the button to add a new prefix
> "
> 
>  "
> is not visible.
> I tried with firefox 41.0.1 and Chrome 45.0.2454.101 m
> is it an expected behavior or an error?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JENA-1046) Button "Add a SPARQL prefix" not visible in fuseki web interface

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated JENA-1046:
-
Attachment: JENA-1046-modal.png
JENA-1046-before.png
JENA-1046-after.png

> Button "Add a SPARQL prefix" not visible in fuseki web interface
> 
>
> Key: JENA-1046
> URL: https://issues.apache.org/jira/browse/JENA-1046
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.0
>Reporter: Gabriele Cornacchia
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: JENA-1046-after.png, JENA-1046-before.png, 
> JENA-1046-modal.png
>
>
> In fuseki web interface.
>  dataset.html page -> tab "query" -> section "PREFIXES"
> the button to add a new prefix
> "
> 
>  "
> is not visible.
> I tried with firefox 41.0.1 and Chrome 45.0.2454.101 m
> is it an expected behavior or an error?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JENA-1046) Button "Add a SPARQL prefix" not visible in fuseki web interface

[Bruno P. Kinoshita (JIRA)]

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

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

Looks like at some point icons and some CSS classes from bootstrap were not 
updated to use custom CSS classes and FontAwesome icons. Updated the CSS, and 
now it should work after the next release.

> Button "Add a SPARQL prefix" not visible in fuseki web interface
> 
>
> Key: JENA-1046
> URL: https://issues.apache.org/jira/browse/JENA-1046
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.0
>Reporter: Gabriele Cornacchia
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Attachments: JENA-1046-after.png, JENA-1046-before.png, 
> JENA-1046-modal.png
>
>
> In fuseki web interface.
>  dataset.html page -> tab "query" -> section "PREFIXES"
> the button to add a new prefix
> "
> 
>  "
> is not visible.
> I tried with firefox 41.0.1 and Chrome 45.0.2454.101 m
> is it an expected behavior or an error?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[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&focusedCommentId=16009201#comment-16009201
 ] 

ASF GitHub Bot commented on JENA-632:
-

Github user tommals commented on the issue:

https://github.com/apache/jena/pull/114
  
Relevant to this thread [Return nested JSON 
results](https://mail-archives.apache.org/mod_mbox/jena-users/201705.mbox/%3Ctrinity-2c35f052-b0a8-4b53-aa95-9963ff11a7a6-1494243601102%403capp-mailcom-lxa06%3E)


> 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.15#6346)

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

[tommals]

Github user tommals commented on the issue:

https://github.com/apache/jena/pull/114
  
Relevant to this thread [Return nested JSON 
results](https://mail-archives.apache.org/mod_mbox/jena-users/201705.mbox/%3Ctrinity-2c35f052-b0a8-4b53-aa95-9963ff11a7a6-1494243601102%403capp-mailcom-lxa06%3E)


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