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.

Feature description

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.

Example

e.g. sample Query highlighting necessary syntax extensions, expected output, or modified/extended result format, endpoint self description mock-up syntax, etc.

Existing Implementation(s)

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.

Compatibility

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

Has this extension/use case some history in the group already? I.e. are there posponed issues or archived mail-threads related to this originating from DAWG?

Related Features

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.

Champions

• Ivan Mikhailov / OpenLink

Use cases

• 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.

References