On 17/01/2023 18:27, Justin wrote:
Hi all,
If you try to run (apache-jena-4.7.0/bin/qparse --print=op --query=b.rq)
qparse on:
```
construct {
?s ?p ?o}
where {
?s ?p ?o
}
```
you get:
```
(bgp (triple ?s ?p ?o))
```
Notice only the where clause gets turned into SPARQL algebra.
I see <https://jena.apache.org/documentation/query/algebra.html> that
"Operations of CONSTRUCT, DESCRIBE and ASK are done on top of algebra
evaluation" which I believe explains why we don't see the construct clause
in the algebra.
Yes - it's the WHERE clause - the part that is executed to get variable
bindings.
The compiled, optimized Op is executed to get a QueryIterator.
I would like to have a Jena SSE style serialization for SPARQL construct
queries. Does anyone have any tips about how this might be done? Feels like
SSE could accommodate it with something like:
Something like:
Add words to org.apache.jena.sparql.sse.Tags
org.apache.jena.sparql.algebra
adding
Algebra.translate(Query) -> Op
call the existing Algebra.compile(Query)
and add (construct)/(describe)/(ask)
+
BuilderQuery along side BuilderOp and other builder.
builder go SSE parser tree to operations.
+
WriterQuery c.f. WriterOp - may not be necessary
+
OpAsQuery to do the reverse of Algebra.translate
It's the execution that's going to be different - other Op all output a
QueryIterator.
Alegbra.execQuery(Op) -> QueryExec (not QueryExecution)
An alternativbe is for (construct) to return QueryIteration which is
fixed as rows of (?subject= ?predicate= ?object= )
See QueryExecDataset for the code that does the CONSTRUCT part.
Andy
```
(construct (bgp (triple ?s ?p ?o))
(bgp (triple ?s ?p ?o)))
```
