[jira] [Updated] (JENA-511) Double-dot (two dots) at the end of triples in the SPARQL generated by the ARQ Serializer
[
https://issues.apache.org/jira/browse/JENA-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greorg Bergman updated JENA-511:
Attachment: src.zip
Double-dot (two dots) at the end of triples in the SPARQL generated by the
ARQ Serializer
-
Key: JENA-511
URL: https://issues.apache.org/jira/browse/JENA-511
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.1
Reporter: Greorg Bergman
Attachments: src.zip
Hello,
I do not know if this is a bug or not, but I have detected a weird behavior
of the ARQ SPARQL Serializer (jena-arq-2.10.1.jar).
When I build a SPARQL Query whose query pattern is defined by an ElementGroup
with only one ElementTriplesBlock containing all the triples, the SPARQL
produced by the ARQ Serializer is ok.
See
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1
.
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2
.
}
But when the SPARQL query pattern is defined by an ElementGroup with two
ElementTriplesBlocks (each one containing several triples), the SPARQL
generated is not anymore syntactically correct. Indeed, it contains a
double-dot (two dots . .) at the end of the last triple of the first
ElementTriplesBlocks.
See
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1
. .
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2
.
}
Is this a bug ?
I have uploaded the source code which prints these two examples :
- the class AvoidBug shows the correct SPARQL query
- the class DisplayBug shows the bad SPARQL query
- Here follows the libs needed to run the project :
org/apache/jena/jena-arq/2.10.1/jena-arq-2.10.1.jar
org/apache/jena/jena-core/2.10.1/jena-core-2.10.1.jar
org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
log4j/log4j/1.2.16/log4j-1.2.16.jar/
xerces/xercesImpl/2.11.0/xercesImpl-2.11.0.jar
xml-apis/xml-apis/1.4.01/xml-apis-1.4.01.jar
org/apache/jena/jena-iri/0.9.6/jena-iri-0.9.6.jar
I gave a look at the jena-arq code and - if this is an issue - the problem
seems to be in the class com.hp.hpl.jena.sparql.serializer.FormatterElement :
(1) a dot is added at the end of the Triple serialisation : see the end of
method formatSameSubject(...) at line 599.
(2) but also during the ElementGroup serialisation when it contains one or
more ElementTriplesBlock : see the middle of the method visit(ElementGroup
el) at line 321.
When an ElementGroup contains two ElementTriplesBlock (or more), a dot is
added during (1) (at the end of the last triple of the first
ElementTriplesBlock processed) but also during (2) at the end of the first
ElementTriplesBlock just after the previous dot. For me, the dot should be
added during either (1) or (2) but not two times.
Hope this helps,
Greorg
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JENA-511) Double-dot (two dots) at the end of triples in the SPARQL generated by the ARQ Serializer
[
https://issues.apache.org/jira/browse/JENA-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greorg Bergman updated JENA-511:
Description:
Hello,
I do not know if this is a bug or not, but I have detected a weird behavior of
the ARQ SPARQL Serializer (jena-arq-2.10.1.jar).
When I build a SPARQL Query whose query pattern is defined by an ElementGroup
with only one ElementTriplesBlock containing all the triples, the SPARQL
produced by the ARQ Serializer is ok.
See
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1 .
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2 .
}
But when the SPARQL query pattern is defined by an ElementGroup with two
ElementTriplesBlocks (each one containing several triples), the SPARQL
generated is not anymore syntactically correct. Indeed, it contains a
double-dot (two dots . .) at the end of the last triple of the first
ElementTriplesBlock.
See
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1 .
.
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2 .
}
Is this a bug ?
I have uploaded the source code which prints these two examples :
- the class AvoidBug shows the correct SPARQL query
- the class DisplayBug shows the bad SPARQL query
- Here follows the libs needed to run the project :
org/apache/jena/jena-arq/2.10.1/jena-arq-2.10.1.jar
org/apache/jena/jena-core/2.10.1/jena-core-2.10.1.jar
org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
log4j/log4j/1.2.16/log4j-1.2.16.jar/
xerces/xercesImpl/2.11.0/xercesImpl-2.11.0.jar
xml-apis/xml-apis/1.4.01/xml-apis-1.4.01.jar
org/apache/jena/jena-iri/0.9.6/jena-iri-0.9.6.jar
I gave a look at the jena-arq code and - if this is an issue - the problem
seems to be in the class com.hp.hpl.jena.sparql.serializer.FormatterElement :
(1) a dot is added at the end of the Triple serialisation : see the end of
method formatSameSubject(...) at line 599.
(2) but also during the ElementGroup serialisation when it contains one or more
ElementTriplesBlock : see the middle of the method visit(ElementGroup el) at
line 321.
When an ElementGroup contains two ElementTriplesBlock (or more), a dot is added
during (1) (at the end of the last triple of the first ElementTriplesBlock
processed) but also during (2) at the end of the first ElementTriplesBlock just
after the previous dot. For me, the dot should be added during either (1) or
(2) but not two times.
Hope this helps,
Greorg
was:
Hello,
I do not know if this is a bug or not, but I have detected a weird behavior of
the ARQ SPARQL Serializer (jena-arq-2.10.1.jar).
When I build a SPARQL Query whose query pattern is defined by an ElementGroup
with only one ElementTriplesBlock containing all the triples, the SPARQL
produced by the ARQ Serializer is ok.
See
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1 .
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2 .
}
But when the SPARQL query pattern is defined by an ElementGroup with two
ElementTriplesBlocks (each one containing several triples), the SPARQL
generated is not anymore syntactically correct. Indeed, it contains a
double-dot (two dots . .) at the end of the last triple of the first
ElementTriplesBlocks.
See
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1 .
.
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2 .
}
Is this a bug ?
I have uploaded the source code which prints these two examples :
- the class AvoidBug shows the correct SPARQL query
- the class DisplayBug shows the bad SPARQL query
- Here follows the libs needed to run the project :
org/apache/jena/jena-arq/2.10.1/jena-arq-2.10.1.jar
org/apache/jena/jena-core/2.10.1/jena-core-2.10.1.jar
org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
log4j/log4j/1.2.16/log4j-1.2.16.jar/
xerces/xercesImpl/2.11.0/xercesImpl-2.11.0.jar
xml-apis/xml-apis/1.4.01/xml-apis-1.4.01.jar
org/apache/jena/jena-iri/0.9.6/jena-iri-0.9.6.jar
I gave a look at the jena-arq code and - if this is an issue - the problem
seems to be in the class com.hp.hpl.jena.sparql.serializer.FormatterElement :
(1) a dot is added at the end of the Triple serialisation : see the end of
method formatSameSubject(...) at line 599.
(2) but also during the
[jira] [Commented] (JENA-510) Incorrect content negotiation with */* in Accept header
[
https://issues.apache.org/jira/browse/JENA-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739622#comment-13739622
]
Andy Seaborne commented on JENA-510:
The content negotiation now ranks matches by weight and then by exactness.
Incorrect content negotiation with */* in Accept header
---
Key: JENA-510
URL: https://issues.apache.org/jira/browse/JENA-510
Project: Apache Jena
Issue Type: Bug
Components: ARQ, Fuseki, TDB
Affects Versions: Jena 2.10.1, Fuseki 0.2.7
Reporter: Sarven Capadisli
Assignee: Andy Seaborne
Priority: Minor
If I'm not mistaken, when */* content type is used in Accept header, content
negotiation is incorrect. For curl -X GET
http://sparql.org/books/sparql?query=SELECT+*+WHERE+%7B+%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
compare:
{noformat}
application/sparql-results+json=
application/sparql-results+json
application/sparql-results+json;q=0.1 =
application/sparql-results+json
*/*=
application/sparql-results+json
*/*;q=0.1 =
application/sparql-results+json
application/sparql-results+json;q=0.1, */*;q=0.9 =
application/sparql-results+json
application/sparql-results+json;q=0.9, */*;q=0.1 = text/csv
application/sparql-results+json;q=0.9, */*;q=0.9 = text/csv
{noformat}
It appears to be that, if the q-value of these two content-types are
compared, the output content-type is incorrect.
Here is an awkward one:
{noformat}
application/sparql-results+xml;q=0.1, */*;q=0.9=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.1=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.9=
application/sparql-results+json
{noformat}
What's going on now?
Just for completeness:
{noformat}
application/sparql-results+xml;q=0.1, application/sparql-results+json;q=0.9
= application/sparql-results+json
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.1
= application/sparql-results+xml
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.9
= application/sparql-results+json
{noformat}
That looks okay.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JENA-510) Incorrect content negotiation with */* in Accept header
[
https://issues.apache.org/jira/browse/JENA-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-510.
Resolution: Fixed
Fix Version/s: Jena 2.10.2
Incorrect content negotiation with */* in Accept header
---
Key: JENA-510
URL: https://issues.apache.org/jira/browse/JENA-510
Project: Apache Jena
Issue Type: Bug
Components: ARQ, Fuseki, TDB
Affects Versions: Jena 2.10.1, Fuseki 0.2.7
Reporter: Sarven Capadisli
Assignee: Andy Seaborne
Priority: Minor
Fix For: Jena 2.10.2
If I'm not mistaken, when */* content type is used in Accept header, content
negotiation is incorrect. For curl -X GET
http://sparql.org/books/sparql?query=SELECT+*+WHERE+%7B+%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
compare:
{noformat}
application/sparql-results+json=
application/sparql-results+json
application/sparql-results+json;q=0.1 =
application/sparql-results+json
*/*=
application/sparql-results+json
*/*;q=0.1 =
application/sparql-results+json
application/sparql-results+json;q=0.1, */*;q=0.9 =
application/sparql-results+json
application/sparql-results+json;q=0.9, */*;q=0.1 = text/csv
application/sparql-results+json;q=0.9, */*;q=0.9 = text/csv
{noformat}
It appears to be that, if the q-value of these two content-types are
compared, the output content-type is incorrect.
Here is an awkward one:
{noformat}
application/sparql-results+xml;q=0.1, */*;q=0.9=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.1=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.9=
application/sparql-results+json
{noformat}
What's going on now?
Just for completeness:
{noformat}
application/sparql-results+xml;q=0.1, application/sparql-results+json;q=0.9
= application/sparql-results+json
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.1
= application/sparql-results+xml
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.9
= application/sparql-results+json
{noformat}
That looks okay.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-510) Incorrect content negotiation with */* in Accept header
[
https://issues.apache.org/jira/browse/JENA-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739628#comment-13739628
]
Hudson commented on JENA-510:
-
SUCCESS: Integrated in Jena_Development_Test #837 (See
[https://builds.apache.org/job/Jena_Development_Test/837/])
JENA-510 : Rewrite content negiotiation code; remove ability to offer ranges
(does not make sense).
Check tests and make all valid; add tests for specific common usages. (andy:
rev 1513851)
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/AcceptList.java
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/MediaRange.java
*
/jena/trunk/jena-arq/src/test/java/org/apache/jena/atlas/web/TestContentNegotiation.java
Incorrect content negotiation with */* in Accept header
---
Key: JENA-510
URL: https://issues.apache.org/jira/browse/JENA-510
Project: Apache Jena
Issue Type: Bug
Components: ARQ, Fuseki, TDB
Affects Versions: Jena 2.10.1, Fuseki 0.2.7
Reporter: Sarven Capadisli
Assignee: Andy Seaborne
Priority: Minor
Fix For: Jena 2.10.2
If I'm not mistaken, when */* content type is used in Accept header, content
negotiation is incorrect. For curl -X GET
http://sparql.org/books/sparql?query=SELECT+*+WHERE+%7B+%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
compare:
{noformat}
application/sparql-results+json=
application/sparql-results+json
application/sparql-results+json;q=0.1 =
application/sparql-results+json
*/*=
application/sparql-results+json
*/*;q=0.1 =
application/sparql-results+json
application/sparql-results+json;q=0.1, */*;q=0.9 =
application/sparql-results+json
application/sparql-results+json;q=0.9, */*;q=0.1 = text/csv
application/sparql-results+json;q=0.9, */*;q=0.9 = text/csv
{noformat}
It appears to be that, if the q-value of these two content-types are
compared, the output content-type is incorrect.
Here is an awkward one:
{noformat}
application/sparql-results+xml;q=0.1, */*;q=0.9=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.1=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.9=
application/sparql-results+json
{noformat}
What's going on now?
Just for completeness:
{noformat}
application/sparql-results+xml;q=0.1, application/sparql-results+json;q=0.9
= application/sparql-results+json
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.1
= application/sparql-results+xml
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.9
= application/sparql-results+json
{noformat}
That looks okay.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-511) Double-dot (two dots) at the end of triples in the SPARQL generated by the ARQ Serializer
[
https://issues.apache.org/jira/browse/JENA-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739642#comment-13739642
]
Andy Seaborne commented on JENA-511:
The problem is that you are creatign a query with two adjacent
ElementTriplesBlock to a group. This syntax form can not arise from parsing
SPARQL.
All adjacent triple patterns are collected into a single element -
EleemntGroup.addTriplePattern does that for you internally.
FormatterElement is assuming queries from legal SPARQL syntax. It's quite
possible to generate abstract syntax trees that can not arise from parsing
SPARQL.
Even if the code printed a legal query (i.e. it implicitly merges the two
ElementTriplesBlock into one), you will not get back the same query as you
initially constructed.
You're welcome to propose a patch for FormatterElement, this one case is quite
natural but it will not be parsed back to the same structure you had
originally. There are other forms that simply can not be printed at all.
Double-dot (two dots) at the end of triples in the SPARQL generated by the
ARQ Serializer
-
Key: JENA-511
URL: https://issues.apache.org/jira/browse/JENA-511
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.1
Reporter: Greorg Bergman
Priority: Minor
Attachments: src.zip
Hello,
I do not know if this is a bug or not, but I have detected a weird behavior
of the ARQ SPARQL Serializer (jena-arq-2.10.1.jar).
When I build a SPARQL Query whose query pattern is defined by an ElementGroup
with only one ElementTriplesBlock containing all the triples, the SPARQL
produced by the ARQ Serializer is ok.
See
{noformat}
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1
.
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2
.
}
{noformat}
But when the SPARQL query pattern is defined by an ElementGroup with two
ElementTriplesBlocks (each one containing several triples), the SPARQL
generated is not anymore syntactically correct. Indeed, it contains a
double-dot (two dots . .) at the end of the last triple of the first
ElementTriplesBlock.
See
{noformat}
SELECT ?x_1
WHERE
{ ?x_1 http://www.test.com/predicate_1 ?y_1 .
?y_1 http://www.test.com/predicate_1 http://www.test.com/resource_1
. .
?x_2 http://www.test.com/predicate_2 ?y_2 .
?y_2 http://www.test.com/predicate_2 http://www.test.com/resource_2
.
}
{noformat}
Is this a bug ?
I have uploaded the source code which prints these two examples :
- the class AvoidBug shows the correct SPARQL query
- the class DisplayBug shows the bad SPARQL query
- Here follows the libs needed to run the project :
org/apache/jena/jena-arq/2.10.1/jena-arq-2.10.1.jar
org/apache/jena/jena-core/2.10.1/jena-core-2.10.1.jar
org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar
log4j/log4j/1.2.16/log4j-1.2.16.jar/
xerces/xercesImpl/2.11.0/xercesImpl-2.11.0.jar
xml-apis/xml-apis/1.4.01/xml-apis-1.4.01.jar
org/apache/jena/jena-iri/0.9.6/jena-iri-0.9.6.jar
I gave a look at the jena-arq code and - if this is an issue - the problem
seems to be in the class com.hp.hpl.jena.sparql.serializer.FormatterElement :
(1) a dot is added at the end of the Triple serialisation : see the end of
method formatSameSubject(...) at line 599.
(2) but also during the ElementGroup serialisation when it contains one or
more ElementTriplesBlock : see the middle of the method visit(ElementGroup
el) at line 321.
When an ElementGroup contains two ElementTriplesBlock (or more), a dot is
added during (1) (at the end of the last triple of the first
ElementTriplesBlock processed) but also during (2) at the end of the first
ElementTriplesBlock just after the previous dot. For me, the dot should be
added during either (1) or (2) but not two times.
Hope this helps,
Greorg
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-512) SSE Tags are used inconsistently
Rob Vesse created JENA-512: -- Summary: SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written report symbols that don't match their tag constants. BuilderExpr appears to get around this by doing case insensitive key lookup which seems very hacky There is also at least one function (isNumeric) which has no Tag constant and no SSE builder defined for it so queries containing this cannot be decoded from algebra. I plan to do two things: - Make expression classes return their Tags constant where they don't already and particularly in the cases where the two values aren't exact matches - Fix the isNumeric case (and any others I discover) where there is no registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740381#comment-13740381 ] ASF subversion and git services commented on JENA-512: -- Commit 1514086 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514086 ] Add Tags.tagIsNumeric and associated SSE builder (JENA-512) SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor Labels: algebra, sse In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written report symbols that don't match their tag constants. BuilderExpr appears to get around this by doing case insensitive key lookup which seems very hacky There is also at least one function (isNumeric) which has no Tag constant and no SSE builder defined for it so queries containing this cannot be decoded from algebra. I plan to do two things: - Make expression classes return their Tags constant where they don't already and particularly in the cases where the two values aren't exact matches - Fix the isNumeric case (and any others I discover) where there is no registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740429#comment-13740429 ] Hudson commented on JENA-512: - SUCCESS: Integrated in Jena_Development_Test #838 (See [https://builds.apache.org/job/Jena_Development_Test/838/]) Add unit tests for isNumeric case (JENA-512) (rvesse: rev 1514087) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/syntax/TestSSE_Builder.java Add Tags.tagIsNumeric and associated SSE builder (JENA-512) (rvesse: rev 1514086) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/Tags.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/builders/BuilderExpr.java SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor Labels: algebra, sse In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written report symbols that don't match their tag constants. BuilderExpr appears to get around this by doing case insensitive key lookup which seems very hacky There is also at least one function (isNumeric) which has no Tag constant and no SSE builder defined for it so queries containing this cannot be decoded from algebra. I plan to do two things: - Make expression classes return their Tags constant where they don't already and particularly in the cases where the two values aren't exact matches - Fix the isNumeric case (and any others I discover) where there is no registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740433#comment-13740433 ] ASF subversion and git services commented on JENA-512: -- Commit 1514101 from [~rvesse] in branch 'jena/trunk' [ https://svn.apache.org/r1514101 ] Use correct Tags constant for E_UnaryMinus (JENA-512) SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor Labels: algebra, sse In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written report symbols that don't match their tag constants. BuilderExpr appears to get around this by doing case insensitive key lookup which seems very hacky There is also at least one function (isNumeric) which has no Tag constant and no SSE builder defined for it so queries containing this cannot be decoded from algebra. I plan to do two things: - Make expression classes return their Tags constant where they don't already and particularly in the cases where the two values aren't exact matches - Fix the isNumeric case (and any others I discover) where there is no registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740467#comment-13740467 ] Hudson commented on JENA-512: - FAILURE: Integrated in Jena_Development_Test #839 (See [https://builds.apache.org/job/Jena_Development_Test/839/]) Use correct Tags constant for E_UnaryMinus (JENA-512) (rvesse: rev 1514101) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java Ensure SPARQL built-in expressions use symbol constants from Tags wherever possible instead of hard coding values in each file (JENA-512) (rvesse: rev 1514099) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Add.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_BNode.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Bound.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Call.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Coalesce.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Conditional.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Datatype.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Divide.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Equals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Exists.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IRI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsBlank.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsIRI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsLiteral.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsNumeric.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsURI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Lang.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LangMatches.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalAnd.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalNot.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalOr.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Multiply.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotEquals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotExists.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotOneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_OneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Random.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Regex.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_SameTerm.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Str.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrConcat.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrDatatype.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrLang.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Subtract.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_URI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryPlus.java SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor Labels: algebra, sse In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written
