Future Work Items

The Working Group has cataloged suggestions for future work that may or may not be considered by future working groups. Inclusion in this list does not imply the working group endorses the idea. This list includes:

• Postponed Issues
• Feature List - includes features that were not adopted for work by the SPARQL 1.1 Working Group
• David Booth: ENCODE_FOR_LOCAL_NAME
• David Booth: str() function on blank node arguments
• David Booth: define prefixes in terms of previously defined prefixes
• Niklas Lindström: extend the DELETE WHERE and CONSTRUCT WHERE shortcuts to more complex patterns in the WHERE clause than just basic graph patterns (CONSTRUCT WHERE) or, respectively, blank-node-free Basic graph patterns (DELETE WHERE).
• SPARQL Protocol support for communicating diagnostics along with a 2XX response to a SPARQL Update operation request
• David Booth: Multi-line comments
• Property paths
  • Curly brace forms for property paths
  • Different operators for counting/non-counting forms of *, +, etc.
  • DISTINCT partial path support
• Service description work in support of graph store protocol
  • Discovering GSP service
  • Templating of indirect graph identification
  • ...
• From Rob Vesse and others -- dynamic function calls
• David Booth: resolve ambiguities caused by implicit graph creation and explicit CREATE operation -- the current working group has left the handling of empty graphs open; due to the existence of both graph-aware and non-graph-aware graph stores we didn't feel there was a sufficient basis for standardisation of either design (i.e., requiring the support of empty graphs or ignoring them). As a generic compromise, the current design allows graph stores to remove any empty graphs at any time, while still remaining compliant with the standard. A future working group may resolve this e.g. by making the distinction between graph-aware and non-graph-aware stores more explicit and standardizing respective behaviours in a stricter way.
• Peter Waher Consider implementation experience of specifying datasets for federated query.