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

Stephen Allen commented on JENA-205:
------------------------------------

That makes sense about Triples instead of Statements.

I note the following statement from the SPARQL spec [1]:

   "The CONSTRUCT query form returns a single RDF graph specified by a graph
    template. The result is an RDF graph formed by taking each query solution in
    the solution sequence, substituting for the variables in the graph 
template, and
    combining the triples into a single RDF graph by set union."

The last sentence specifically calls for a set union rather than a bag union.  
Wouldn't having duplicates be non-standard?  Not that I think it matters too 
much as you say, since most people will probably put the results into some sort 
of RDF data model.

Would it make sense for a query language extension like "CONSTRUCT" and 
"CONSTRUCT DISTINCT" to specify which you wanted?  Although given that it is 
already defined as a set in SPARQL 1.0, it might have to be something ugly like 
"CONSTRUCT <something>" where something could be "BAG" or "REDUCED" or 
"DUPLICATES_ALLOWED"

Additionally, I can imagine future features like CONSTRUCT JSON, where it could 
be more plausible that you definitely want to eliminate duplicates, since that 
feature could be used without having a heavyweight RDF library available to 
parse the results.

[1] http://www.w3.org/TR/rdf-sparql-query/#construct


                
> Streaming results for CONSTRUCT queries
> ---------------------------------------
>
>                 Key: JENA-205
>                 URL: https://issues.apache.org/jira/browse/JENA-205
>             Project: Jena
>          Issue Type: Improvement
>          Components: ARQ, Fuseki
>            Reporter: Stephen Allen
>            Assignee: Stephen Allen
>            Priority: Minor
>
> It would be useful to have CONSTRUCT queries that streamed results.  An 
> additional method on QueryExecution that returned an Iterator<Statement> (or 
> something similar to that [1]) would provide the necessary access.
> Implementationwise, the application of Bindings to the CONSTRUCT template is 
> already streaming, we would simply need to perform a distinct operation on 
> the Triples that are created.  We could use a DistinctDataNet to get 
> semi-streaming with spill-to-disk functionality.
> Additionally, for this to be useful for Fuseki, we also need an RDF/XML 
> serializer that can operate on an Iterator<Statement> instead of a Model.
> [1] Prefix mappings would probably be nice for serializers that consume this 
> iterator.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to