[
https://issues.apache.org/jira/browse/JENA-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne 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 >>>
{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
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
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
> 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 >>>
> {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
