We note that OWL QL has a notion of a handle on a query. Such a handle may be used in order to obtain additional results for a query.
An implementation is free to process this in any manner of its choice, from keeping an open cursor to re-evaluating the query with different offset-limit settings.
e.g. sample Query highlighting necessary syntax extensions, expected output, or modified/extended result format, endpoint self description mock-up syntax, etc.
List existing applications, if applicable (e.g. aggregates, we do not want a use case page for every implementation of aggregates, but all implementations listed per use case. Different syntax proposals can be listed as separate subsections in the Examples section)
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.
- OpenLink do not consider this as particularly critical but also would not object to this feature being copied from OWL QL into SPARQL.
A description of one or more use cases, the solution of which requires this feature. Multiple use cases can be added to each feature.