Feature: Timeout And Resource Constraints
It should be possible to restrict the execution time of the query, esp., for interactive client applications.
In an open web environment, specially if queries are being federated, a best effort approach will often be required. This means omitting results from sources which do not answer in the required time. Also, in interactive situations such as faceted browsing, results may cease to be relevant if they are not returned within a short time limit. For efficient resource utilization, such timeouts ought to be enforced server side.
For this purpose, we propose an extra timeout parameter for the different SPARQL request formats. There should be also an optional parameter that indicates that the client agrees to get partial result set if the full result set is not composed during the timeout interval, the default behaviour is service-specific bu the recommended default is "return everything or nothing, but not a part".
An application that seaches for "see also" links while a user reads some web-page. In this case it is better to shoulw something while the user reads than wait for full result set that may come few minutes after the user leaves the page.
- Virtuoso is supporting it in next version.
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.
A description of one or more use cases, the solution of which requires this feature. Multiple use cases can be added to each feature.