From SPARQL Working Group
Feature: Cost Model Interface
SPARQL end point should be able to report its query cost model details; thi si especially important for clients that can generate federated queries.
For federated query optimization, a SPARQL end point may expose a hook into its query cost model. Thus, given the text of a SPARQL query, the implementation would respond with its guess of the quantity of solutions produced and query execution time. The implementation cost is small, since implementations must anyhow have a cost model. The expected user of such a service would be a federated SPARQL query optimizer.
e.g. sample Query highlighting necessary syntax extensions, expected output, or modified/extended result format, endpoint self description mock-up syntax, etc.
Garlik's JXT implements this feature, using an additional argument in the SPARQL protocol.
Existing Specification / Documentation
List any existing text that attempts a formal definition of this extension. This could be a draft specification, API or syntax documentation, etc.
Extensions should be upwards compatible with the previous SPARQL spec. Although the charter does not formally bind us to this requirement, it rule should only be violated in exceptional cases. In case your extension possibly raises any compatibility issues, these should be detailed here.
Links to postponed Issues
List and possibly link to other use cases or extensions that relate to that use case. That will help us grouping them together in the end.
- Ivan Mikhailov / OpenLink
- Join order for single federated join.
- In interactive search application, a quick check whether the user should refine his search without loading the server with running the query that will probably return millions of hits.
- A federated join that can be expresses in few different "styles" or on few different servers, like local join of federated unions versus local union of federated joins.