incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Allen (Commented) (JIRA)" <>
Subject [jira] [Commented] (JENA-205) Streaming results for CONSTRUCT queries
Date Mon, 30 Jan 2012 22:35:10 GMT


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

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.


> Streaming results for CONSTRUCT queries
> ---------------------------------------
>                 Key: JENA-205
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message