Because it isn't a valid semantics preserving optimization. ARQ only applies optimizations that preserve the semantics of the query, the fact that this is ultimately a CONSTRUCT query doesn't change the semantics of the query evaluation itself, merely the final RDF produced. Making the rewrite you suggest changes the semantics of the query significantly so ARQ is never going to automatically apply that for you.
ARQ allows you to write and use custom optimizers/query rewriters/query engines if you so wish. If you know your data and the types of queries that should/shouldn't be being written then you can provide your own custom components to handle this "optimisation" for your use case. Thanks, Rob On 19/10/2021, 10:09, "Élie Roux" <[email protected]> wrote: > As others pointed out semantically the evaluation of the two query forms yields very different intermediate results. It's only the presence of the post-processing CONSTRUCT stage that happens to strip out the duplicates/unusable results. Any optimizations MUST preserve the overall semantics of the query to ensure they yield the same results, so no you couldn't apply an optimization in this case. In this specific case CONSTRUCT happens as a post-processing step as part of producing the final query results, it's not actually within the portion of query evaluation that is subject to ARQs optimizer. Thanks! I still don't understand though... is there a reason why the ARQs optimizer can't have a boolean flag telling it it can optimize things for a CONSTRUCT? Best, -- Elie
