CONSTRUCT GRAPH

[jindrichmynarz]

Why?

Named graphs are increasingly used for data management and data modelling. SPARQL 1.1 Query offers no way to produce RDF quads in named graphs. The CONSTRUCT clause is limited to producing RDF triples. This is possible only indirectly via SPARQL 1.1 Update by running an INSERT update operation, followed by dumping the created named graphs. This work-around requires write access to a SPARQL endpoint and post-processing the exported data, since there's no standards-based way to request data in a quad-based RDF format.

What could it look like?

CONSTRUCT query form can be extended to produce named graphs.

Previous work

Apache Jena already allows to CONSTRUCT named graphs (https://jena.apache.org/documentation/query/construct-quad.html).

Considerations for backward compatibility

This is a change that grows SPARQL, so that its implementation would not break any SPARQL 1.1 applications. It is backwards-compatible, however, it is not forwards-compatible, since non-SPARQL 1.2 implementations would break due to the required changes in query syntax.

[RickMoynihan]

I came here specifically to register this issue as it is a frequent source of frustration for myself and some of my colleagues at Swirrl. Named graph's and quads as they stand in SPARQL 1.1 feel to me like an unfinished feature due to the lack of this; and this is in my mind the most obvious omission in SPARQL 1.1 and candidate feature for inclusion in SPARQL 1.2. It's unglamarous, but would be very useful for data management tasks.

[cygri]

So, if one wanted to dump the store’s entire dataset, how would one do that? Would it be this, if we wanted to be precise and retain empty graphs?

CONSTRUCT {
    ?s1 ?p1 ?o1
    GRAPH ?g2 { ?s2 ?p2 ?o2 }
    GRAPH ?g3 { }
}
WHERE {
    { ?s1 ?p1 ?o1 }
    UNION
    { GRAPH ?g2 { ?s2 ?p2 ?o2 } }
    UNION
    { GRAPH ?g3 { FILTER NOT EXISTS { ?s ?p ?o } } }
}

That is very verbose for such a basic task.

What would happen if GRAPH ?var { ... } in the construct template has ?var unbound or a non-IRI? Would the triples be discarded, or would they go into the default graph?

Does this create a case for having multiple CONSTRUCT/WHERE queries in a single message, with the query result being the dataset union of the individual CONSTRUCT+WHERE queries?

[afs]

There does seem to be a use case for a single request with multiple CONSTRUCT templates, maybe as ;

CONSTRUCT {}
WHERE {}
;
CONSTRUCT {} 
WHERE {} 

or a modification to the CONSTRUCT form such as (sketch):

CONSTRUCT { } WHERE { } , { } WHERE { } ,  { } WHERE { }

CONSTRUCT { } WHERE { } 
AND  { } WHERE { } 
AND  { } WHERE { }

[cygri]

The multi-CONSTRUCT request form would synergise well with some sort of named subquery mechanism such as the Blazegraph WITH/INCLUDE feature (see #44). This would allow factoring out common parts of WHERE clauses, reducing repetition within the multi-CONSTRUCT request.