Support for SPARQL CONSTRUCT clauses#985
Conversation
| {"@id" "?s" "friendname" "?friendName"} | ||
| {"@id" "?friend" "name" "?friendName"} | ||
| {"@id" "?friend" "num" "?friendNum"}]})))) | ||
| #_(testing "bnode template" |
There was a problem hiding this comment.
Using bnodes in construct templates produces nondeterministic responses since we process results in parallel. I don't have a good solution for this yet, so the flaky tests are commented out.
| (cond-> {"@graph" (->> results | ||
| (sort-by #(get % id-key)) | ||
| (partition-by #(get % id-key)) | ||
| (mapv display/nest-multicardinal-values))} |
There was a problem hiding this comment.
This sorting, partitioning, and nesting is not strictly required by the spec, but may greatly improve usability. If users are mainly using construct to directly inject the results into another graph processor, then this is probably unnecessary. If they are trying to use the json-ld document directly, this is probably very useful. Until we discover which use case is more common I've tried to strike a middle path.
|
As of this PR, we do not support anonymous blank node syntax in SPARQL, like this: Support for anonymous blank nodes is planned for a subsequent PR. |
f74b898 to
4b1fd82
Compare
8810e4f to
8c180a7
Compare
|
Rebased on main. |
src/clj/fluree/db/query/exec.cljc
Outdated
| (cond (:select-one q) (async/take 1 result-ch) | ||
|
|
||
| (:construct q) | ||
| (-> (async/into [] result-ch) |
There was a problem hiding this comment.
this is just a suggestion you can take or leave, but i think you can do this and the clause below in one step using async/transduce
(async/transduce identity
(completing conj (partial select/wrap-construct q))
[]
result-ch)
(async/transduce identity
(completing conj (partial select/wrap-sparql q))
[]
result-ch)I haven't tested this, but I think it should work.
4b1fd82 to
1193d39
Compare
28a83a3 to
e997302
Compare
|
Rebased on main via #973 |
The official grammar only has it in all caps, but even the examples in the spec use lower case, so we may as well support it.
Also added compact iris to construct results, which required holding on to the original unparsed context.
Since solutions are processed concurrently there's no guarantee on the order blank node labels will be assigned.
e997302 to
6b03026
Compare
|
Updated to account for the removal of the |
Return an RDF graph result using
CONSTRUCT, according to the SPARQL spechttps://github.com/fluree/core/issues/170
The specification does not specify how compact the results should be, so I've elected to "flatten" the data so that all of a subject's predicates are grouped into one json object. This does come at a performance penalty, so we could elide that step and still be compliant, but I figured this way is perhaps more usable than the alternative, which is each triple produces a unique object.
I've also elected to treat all objects as multicardinal values returned in arrays, even if there's only a single item. We could do the extra step of unpacking single values, but that complicates result processing and I elected not to do it unless someone asks for it, in which case I would be happy to add it.