SPARQL Working Group Charter

Scope

The 2 July 2009 Working Draft of SPARQL New Features and Rationale establishes the scope of this charter (and includes more rationale than shown below).

Compatibility Expectation

For all new features, backwards compatibility with the current version of SPARQL is of great importance. All queries, that are valid in the January 2008 version of SPARQL, should remain valid in the new version and should produce identical results.results, except in the case of errata. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of additions.

New Features

The group plans to specify the following features, grouped as follows:

1. Additions to the SPARQL Query Language
2. Service Description
3. Update
4. Entailment

The 2 July 2009 draft of SPARQL New Features and Rationale identifies two lists of features: "Required features" and "Time-permitting features". The former includes features whose inclusion in the final recommendations is required for the Working Group to successfully complete its charter, whereas the latter includes features that the Working Group intends to add to the final recommendation, but which may be abandoned if the Working Group has insufficient time or resources. Working Group members and the community are encouraged to develop the time-permitting features. The Working Group is expected to give priority in allocating resources to the required features until they are completed.

Additions to the SPARQL Query Language

Required features:

• Aggregate functions. Aggregate functions will allow operations on the query engine side such as counting, numerical min/max/average and so on, by operating over columns of results. Examples are COUNT, AVG (for average), SUM, MIN, MAX, etc. The group will select a set of standard aggregatesaggregates, borrowing from SQL and XPath when appropriate, and define their semantics within SPARQL.
• Subqueries. This feature will allow nesting the results of a query within another query. In the current SPARQL version such patterns require multiple steps: retrieving the results of a first query, parsing them with dedicated scripts, and then launching the second query.
• Negation. In the current SPARQL Recommendation “Negation As Failure” is possible by combining OPTIONAL, FILTER and !BOUND. It is yet difficult to write and can be a burden for learning and using SPARQL. Hence, dedicated language constructs for expressing negation will be introduced.
• Project expressions. This feature will allow one to return the values of expressions over result bindings, rather than just RDF terms in the store covers a large class of queries. An example is “(?unit_price * ?quantity AS ?total_price)” as part of the SELECT clause.

Time permitting:

• Additions to the query language syntax. Certain limitations of the current SPARQL language syntax cause unnecessary barriers for learning and using SPARQL. Specific uses are the usage of commas between variables (currently not allowed) or an IN and BETWEEN operator to abbreviate disjunction and comparisons within FILTER expressions.
• Property paths. Many classes of queries over RDF graphs require searching data structures that are hierarchical and involve arbitrary-length paths through the graphs. Examples include retrieving all the elements of an RDF collection, searching for the direct and indirect superclasses of a class, etc. It is not possible to express such queries using the current SPARQL Recommendation.
• Commonly used SPARQL functions. Many SPARQL implementations support functions beyond those required by the current SPARQL specification. There is little to no interoperability between the names and semantics of these functions for common tasks such as string manipulation. The group will select a set of standard SQL and XPath functions and define their semantics within SPARQL.
• Basic federated query. SPARQL is a concise query language to retrieve and join information from multiple RDF graphs via a single query. In many cases, the different RDF graphs are stored behind distinct SPARQL endpoints, and dedicated language constructs will allow for more efficient queries in such configurations.
• The group may make minor changes to SPARQL in order to align with changes and clarification of RDF and Turtle coming from the RDF Working Group, being careful not to require burdensome changes for existing SPARQL deployments.

Service Description

Required feature:

• Service description. Given the variety of SPARQL implementations, and differences in datasets and extension functions, this feature will provide a method for discovering a SPARQL endpoint's capabilities and summary information of its data in a machine-readable way.

Update

Required features:

• SPARQL/UpdateSPARQL Update language. To change an RDF graph (either adding, updating or removing statements as well as adding statements from one graph to another or to the default graph of a triple store) one would currently have to use a programming language and one of several APIs. In other query languages, notably SQL, there are mechanisms to change the data in the database. To allow RDF graphs to be manipulated the same way and avoid using third-party APIs, an update language is needed.
• Protocol enhancements for update. The group will also define protocol to update RDF graphs using ReSTful methods.

Entailment

Time permitting:

• Entailment. Many software systems that support entailment regimes such as OWL dialects, RDF Schema, or custom sets of entailment rules expressible in RIF, extend the semantics of SPARQL Basic Graph Pattern matching to apply to entailments other than simple entailment. The formal semantics of these SPARQL/Query extensions are not standardized, and query writers cannot currently be guaranteed interoperable behavior when working with multiple query engines that extend SPARQL with the same entailment regime. The goal is to provide such standard semantics for some of those regimes, namely OWL 2 dialects and profiles, RDFS, RIF BLD and RIF Core, or a subset of these.