Replies: 3 comments
-
This is a good proposal which encourage subquery reuse, makes queries shorter and more readable. One can discuss whether named subqueries should always be scoped to the outer query, or can be defined globally, but that's a side issue. I also like the use of the My main remark is about the example where the subquery is references by name inside the UNION:
I agree with the author that it makes it easier for the optimiser to figure out that it should first evaluate
and
BGPs (or even inline the text for To sum up, my point is that while the proposal makes it easier to influence the evaluation order, it does not provide tools to define that order, it's still uncorrelated bottom-up execution model. It matters, for example, if the subquery cannot be executed before some outer SPARQL patterns supplies values for certain variables, a-la EXISTS sometimes requires. This is what correlated execution does, see an example at https://docs.stardog.com/query-stardog/stored-query-service#correlated-subqueries: the idea is similar, except that the subquery is invoked via [1] mapping variables is important when subqueries are shared across queries and there might be variable clashes, e.g. you want to call
|
Beta Was this translation helpful? Give feedback.
-
@klinovp Thanks for your feedback!
Yes, I was also thinking about using FROM for graph data.
I see. You are the wrong person to bring up examples, like the UNION query, that proves my point only on not well-optimized query engines 😉️
I agree with that for the case that the query runs on one endpoint, but is it also the case for federated queries? Besides readability, I would gain the most from this proposal with federated queries in my daily work.
I see what you are doing and why you are doing it like this. But wouldn't it be great to have better native support for features like this in SPARQL? We have too many hacks to add features in a way that the SPARQL language is not broken. I will add a comment in the SPARQL 1.2 repository. Let's hope it will be picked up. w3c/sparql-dev#44 |
Beta Was this translation helpful? Give feedback.
-
Interesting idea. Another use case is to have a number of updates statements using the named query results. This suggests globally scoped named queries. It makes it clear it is calculated before the query or update. Example:
The We might sometime have other kinds of variables that can't currently be returned as result, such as lists or paths. |
Beta Was this translation helpful? Give feedback.
-
Discussion about the SPARQL Named Query blog post
Beta Was this translation helpful? Give feedback.
All reactions