Chained CONSTRUCT queries

[BenjaminHofstetter]

Why?

The context of this request are web applications and generated queries. In applications I can merge the result of several construct queries into one dataset. The advantage of having many smaller queries is reusability of such a query. And these queries are smaller and have a well defined function e.g. fetch a person or fetch a persons friends. These queries are better maintainable because the code to generate such a query is not very complex.

But for web apps it much better to have just one query and not many. To fetch all the required data in one request. If i generate just one construct query to fetch all the data ...

1. the generating code complexity increases
2. this query is not or at least less reusable
3. i will loose the well defined functions because i loose the small queries
4. the query is hard to read

It would be nice to send many construct in one query and get one dataset back.

Previous work

I solved this with SPARQL 1.1 with a function that merges construct queries into one query. It works like this.

1. merge prefixes
2. merge CONSTRUCT Templates and rename variables
3. Create a new WHERE and combine all WHERE bodies with UNIONS and rename it's variables

The solution works and is very convenient to use. The reusability of the queries provides a lot of flexibility. The drawback of this solution is the code to merge construct queries. it uses a query parser and renaming variables is not that nice.

Proposed solution

Just send many construct queries in one request get a merged graph back.

CONSTRUCT {
    ?s1 ex:prop1 ?o1 
}
WHERE {
    ?s1 ex:prop1 ?o1 
}
CONSTRUCT {
    ?s2 ex:prop2 ?o2
}
WHERE {
    ?s2 ex:prop2 ?o2
}

Considerations for backward compatibility

[rubensworks]

Related to nested CONSTRUCT queries (#33)

[ericprud]

I assume the semantics accumulate a single output graph, i.e.

WHERE {
    ?s1 ex:prop1 ?o1 
}

matches ex:prop1 in the original dataset,

CONSTRUCT {
    ?s1 ex:prop1 ?o1 
}

adds (in this case, identical) triples to the output graph

WHERE {
    ?s2 ex:prop2 ?o2
}

matches ex:prop2 in the same (original) dataset,

CONSTRUCT {
    ?s2 ex:prop2 ?o2
}

adds these triples to the same constructed output graph

[VladimirAlexiev]

@BenjaminHofstetter interesting proposal.

• use semicolon to separate the queries. That's what SPARQL UPDATE uses
• @cygri's https://tarql.github.io/ allows this , see "consecutive SPARQL 1.1 CONSTRUCT queries".
  • subsequent queries can use triples made by previous queries. But I think this pertains only to tarql, whose input dataset is a single TSV row
• how often do you use multiple DISCONNECTED queries in your apps? Please elaborate: how do you get the ids of the queries objects?

[BenjaminHofstetter]

I use them often. The best thing is I describe what I do. I use SHACL shapes in my application. And I derive SPARQL construct queries from these Shapes. When the query returns I validate the result with these Shapes. With that approach I can (re)use the shapes and the derived query everywhere. e.g. I have a Person Shape and UI Metadata Shape (for UI display things like color and icon). I Can then derive the SPARQL queries and execute them and merge the datasets or I can merge the construct query into one query (what I am actually doing right now).