You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2013/08/14 15:11:48 UTC

[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-tabpanel&focusedCommentId=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