Construct instead of Select?

[VladimirAlexiev]

https://github.com/rubensworks/sparqljson-to-tree.js:

convert SPARQL query results to a tree-based structure. This is done by splitting combining variables prefix-based

Isn't it possible to use Construct queries, thus obviating the need for this conversion?
Isn't SPARQL Construct powerful enogh?

we require a mapping to be passed inside the context that defines which variables are singular

Such info is available in the the GQL schema and can be retrospected (#6)

[rubensworks]

Isn't it possible to use Construct queries, thus obviating the need for this conversion?
Isn't SPARQL Construct powerful enogh?

This may indeed be possible, and might work well for clean nested property paths. However, when things like fragments and aliases come into the mix, then I think this won't be that straightforward anymore, as there might not be a direct mapping to RDF triples anymore.

I haven't looked into this possibility in detail yet, so I could be wrong.

Such info is available in the the GQL schema and can be retrospected

In this project we don't require GraphQL schemas. But indeed, if one were available, this mapping could be done automatically.

[VladimirAlexiev]

You write in the paper "GraphQL is however not as expressive as SPARQL, as GraphQL queries represent trees, and not full graphs as in SPARQL".
It's funny you say this, yet use rectangular SELECT results. But IMHO SPARQL is not good at getting complex objects: try getting a complex object shape from a complex query that finds these objects, and you'll be pulling your hair soon.
(On the other hand GQL doesn't have standardized conditions (WHERE) and aggregations, whereas SPARQL has.)

If you agree with #6 that you shouldn't make a Cartesian product but use Union, then you'll be returning very wide but sparse SELECT tables. Although CONSTRUCT implementations are usually based on an underlying select, at least they compact the result into a graph.