SPARQL Working Group Charter
This charter has been replaced by the June 2011 Version.
The mission of the SPARQL Working Group, part of
the Semantic Web Activity, is to
develop SPARQL, the query language for the Semantic Web. The scope of this charter is to extend SPARQL technology to include some
of the features that the community has identified as both desirable and
important for interoperability based on experience with the initial
version of the standard.
End date |
31 July 2011 |
Confidentiality |
Proceedings are public
|
Initial Chairs |
Lee Feigenbaum
Axel Polleres |
Team Contacts
(FTE %: 30)
(Same as previous charter)
|
Sandro Hawke (20%)
Ivan Herman (10%) |
Usual Meeting Schedule |
Teleconferences: Weekly
Face-to-face: 1-2 per year |
Background
In January 2008, the RDF Data
Access Working Group published three SPARQL recommendations (Query
Language, Protocol,
and Results
Format). Since then, SPARQL has become very widely deployed.
Usage and implementation of SPARQL have revealed
requirements for additions to the query language and protocol
that are needed by
applications. Some of those were known during
development of the first standard, but at the time there was
insufficient experience to include them in the standard. Current
implementation experience and feedback from the user community makes it now
feasible to handle some of those issues in a satisfactory manner.
In February 2009, W3C
renamed the group the "SPARQL Working Group" with a charter to enumerate the features expected to be included
in the next revision of SPARQL, which it did by publishing
SPARQL New Features and Rationale. See additional historical notes below.
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. 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:
- Additions to the SPARQL Query Language
- Service Description
- Update
- 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 aggregates from SQL and XPath 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.
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/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.
Deliverables
The group expects to publish the following documents
consistent with the above scope. The titles of the documents are indicative only.
- SPARQL Query Language for RDF, new version,
Recommendation.
- SPARQL Update Language for RDF,
Recommendation.
- SPARQL Protocol for RDF, new version, Recommendation.
- SPARQL Query Results XML Format, new version,
Recommendation.
- Serializing SPARQL Query Results in JSON, new version,
Working Group Note.
Some of the new features might be published as separate documents that would not be necessarily part of the “Core” Query Language.
The group may revise the SPARQL Results Format Recommendation, but it is not clear as of this charter whether that will prove necessary.
Test Suites
The group expects to create a test suite for each specification.
Errata
The group will also take into consideration the errors on the documents
reported by the community since the publication of of the SPARQL documents in
January 2008, and stored in the public
archives of the relevant mailing list.
Milestones
Milestones
Note: The group will document significant
changes from this initial schedule on the group home page. |
Specification |
FPWD |
LC |
CR |
PR |
Rec
|
SPARQL Query Language, new version |
September 2009 |
March 2010 |
May 2010 |
July 2010 |
August 2010 |
SPARQL Update Language |
September 2009 |
March 2010 |
May 2010 |
July 2010 |
August 2010 |
SPARQL Protocol, new version |
September 2009 |
March 2010 |
May 2010 |
July 2010 |
August 2010 |
SPARQL Return XML Format, new version |
September 2009 |
March 2010 |
May 2010 |
July 2010 |
August 2010 |
Timeline View Summary
(As a clarification: in the list below “T” stands for the time when the new charter enters into effect, and “X” for the number of months)
- T: First teleconference
- T+3: First public Working Draft for Recommendation track documents
- T+4: First face-to-face meeting (optional)
- T+9: Last Call Working Draft for Recommendation track documents
- T+12: Second face-to-face meeting (optional)
- T+11: First Working Draft for the JSON result format Working Group
Note
- T+12: Proposed Recommendation for Recommendation track documents
- T+11: Candidate Recommendation for Recommendation track documents
- T+13: Publication of the JSON result format Working Group Note
- T+13: Recommendation for all three Recommendation track documents
Dependencies
W3C Groups
- Semantic Web Coordination
Group
- To ensure synchronization with all other Working and Interest Groups in
the Semantic Web Activity
- OWL and RIF Working Groups
- On interoperability measures with OWL and/or RIF inference
regimes, the details should be checked with the relevant group(s).
- Internationalization Activity
- To ensure that any extension to string related filters and operators
would work in an international setting
- XML Query Working Group
- To take into account possible extensions and changes in the
specification of the XQuery 1.1/XPath Functions & Operators, and
experiences in the XQuery Update Facility
work.
Participation
To be successful, the SPARQL Working Group is expected to have 10 or more
active participants for its duration. Effective participation to SPARQL
Working Group is expected to consume one work day per week for each
participant; two days per week for editors.
Participants are reminded of the Good Standing
requirements of the W3C Process.
Communication
This group primarily conducts its work on the Member-only mailing list
public-rdf-dawg@w3.org (with a publicly visible archive) .
Information about the group (deliverables, participants, face-to-face
meetings, teleconferences, etc.) is available from the SPARQL Working Group home
page.
Decision Policy
As explained in the Process Document (section 3.3),
this group will seek to make decisions when there is consensus. When the Chair
puts a question and observes dissent, after due consideration of different
opinions, the Chair should record a decision (possibly after a formal vote) and
any objections, and move on.
- When deciding a substantive technical issue, the Chair may put a question
before the group. The Chair must only do so during a group
meeting, and at least two-thirds of participants in Good
Standing must be in attendance. When the Chair conducts a formal vote to
reach a decision on a substantive technical issue, eligible voters may vote
on a proposal one of three ways: for a proposal, against a proposal, or
abstain. For the proposal to pass there must be more votes for the proposal
than against. In case of a tie, the Chair will decide the outcome of the
proposal.
- This charter is written in accordance with Section 3.4,
Votes of the W3C Process Document and includes no voting procedures
beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy
(5 February 2004 Version). To promote the widest adoption of Web standards, W3C
seeks to issue Recommendations that can be implemented, according to this
policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see
the W3C Patent Policy
Implementation.
About this Charter
This charter has been created according to section 6.2 of the
Process Document. In the event
of a conflict between this document or the provisions of any charter and the
W3C Process, the W3C Process shall take precedence.
Historical notes:
- In December 2008, W3C approved a charter for this group that encompassed both requirements development and
standardization work. That charter was approved, but then W3C acted
on requests to split the charter in two to better delimit the scope.
- In February 2009, W3C approved a "Phase I" charter limited to documentation of requirements.
- This charter (Phase II) describes the standardization effort based
on those requirements.
Eric Prud’hommeaux, Ivan Herman
Copyright © 2009
W3C ® (MIT , ERCIM
, Keio), All Rights Reserved.
$Id: sparql-phase-II-charter.html,v 1.44 2012/06/12 10:53:32 sandro Exp $