Abstract

This document is an overview of SPARQL 1.1. It provides an introduction to a set of W3C specifications that facilitate querying and manipulating RDF graph content on the Web or in an RDF store.

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Set of Documents

This document is beingpublishedasone of asetof11documents:elevenSPARQL1.1RecommendationsproducedbytheSPARQLWorkingGroup:

SupportTheadvancementofEndorsedByW3C

This ProposedRecommendationissupporteddocumenthasbeenreviewed by thedispositionofcommentsonthepreviousdrafts,theTestSuite,W3CMembers,bysoftwaredevelopers, and byotherW3Cgroupsandinterestedparties,andisendorsedby the listofimplementations(withtestresults).NoEndorsementPublicationDirector as a ProposedRecommendationdoesnotimplyendorsementbytheW3C Membership.ThisRecommendation.It is a draftstable document and may be updated,replacedusedasreferencematerial or obsoletedbyotherdocumentsatanytime.Itcitedfromanotherdocument.W3C'sroleinmakingtheRecommendation is inappropriateto citedrawattentiontothespecificationandtopromoteitswidespreaddeployment. This documentasotherthanworkinprogress.enhancesthefunctionalityandinteroperabilityoftheWeb.

With SPARQL 1.1 one can query such graphs, load them into RDF stores and manipulate them in various ways.

2 SPARQL 1.1 Query Language

Assuming the graph data from above is loaded into a SPARQL service (i.e., an HTTP service endpoint that can process SPARQL queries), the SPARQL 1.1 Query Language can be used to formulate queries ranging from simple graph pattern matching to complex queries. For instance, one can ask using a SPARQL SELECT query for names of persons and the number of their friends:

Just like in the earlier SPARQL1.0 specification [SPARQL-Query] from 2008, complex queries may include union, optional query parts, and filters; new features like value aggregation, path expressions, nested queries, etc. have been added in SPARQL 1.1. Apart from SELECT queries - which return variable bindings - SPARQL supports ASK queries - i.e. boolean "yes/no" queries - and CONSTRUCT queries - by which new RDF graphs can be constructed from a query result; all the new query language features of SPARQL 1.1 are likewise usable in ASK and CONSTRUCT queries.

Compared to SPARQL1.0, SPARQL 1.1 adds a number of new features to the query language, including subqueries, value assignment, path expressions, or aggregates - such as COUNT, as used in the above example query - etc.

The SPARQL 1.1 Query Language document defines the syntax and semantics of SPARQL 1.1 queries and provides various examples for their usage.

Results of SELECT queries in SPARQL comprise bags of mappings from variables to RDF terms, often conveniently represented in tabular form. For instance, the query from Section 2 has the following results:

?name

?count

"Alice"

3

"Bob"

1

"Charlie"

1

In order to exchange these results in machine-readable form, SPARQL supports four common exchange formats, namely the Extensible Markup Language (XML), the JavaScript Object Notation (JSON), Comma Separated Values (CSV), and Tab Separated Values (TSV). These results formats are described in three different documents:

Here, the first part of the pattern in the WHERE part is still matched against the local SPARQL service, whereas the evaluation of the pattern following the SERVICE keyword is delegated to the respective remote SPARQL service.

5 SPARQL 1.1 Entailment Regimes

SPARQL could be used together with ontological information in the form of, for example, RDF Schema or OWL axioms.
For instance, let us assume that - apart from the data about Alice - some ontological information in the form
of RDF Schema [RDF-Schema] and OWL [OWL2-Overview]
constructs defining the FOAF vocabulary is loaded into our example SPARQL service.

A SPARQL engine that does not consider any special entailment regimes (on top of standard simple entailment) would not return any results for this query, whereas an RDF Schema aware query engine will return

6 SPARQL 1.1 Update Language

The SPARQL 1.1 Update specification defines the syntax and semantics of SPARQL 1.1 update requests and provides various examples for their usage. Update operations can consist of several sequential requests and are performed on a collection of graphs in a Graph Store. Operations are provided to update, create and remove RDF graphs in a Graph Store.

For instance, the following request inserts a new friend of Alice named Dorothy into the default graph of our example SPARQL service and thereafter deletes all names of Alice's friends with an English language tag.

As the second operation shows, insertions and deletions can be dependent on the results of queries to the Graph Store; the respective syntax used in the WHERE part is derived from the SPARQL 1.1 Query Language.

7 SPARQL 1.1 Protocol for RDF

The SPARQL 1.1 Protocol for RDF defines how to transfer SPARQL 1.1 queries and update requests to a SPARQL service via HTTP. It also defines how to map requests to HTTP GET and POST operations and what respective HTTP responses to such requests should look like.

For instance, the query from Section 3 above issued against a SPARQL query service hosted at http://www.example.org/sparql/ could according to this specification be wrapped into an HTTP GET request (where the query string is URI-encoded):

8 SPARQL 1.1 Service Description

According to this specification, a service endpoint, when accessed via an HTTP GET operation without further (query or update request) parameters should return an RDF description of the service provided. For instance, the following HTTP request:

GET /sparql/ HTTP/1.1
Host: www.example.org

issued against the SPARQL endpoint hosted at http://www.example.org/sparql/ should return an RDF description, using the Service Description vocabulary. Such a description provides, for instance, information about the default dataset of the respective endpoint, or about SPARQL query language features and entailment regimes that are supported.

9 SPARQL 1.1 Graph Store HTTP Protocol

For many applications and services that deal with RDF data, the full SPARQL 1.1 Update language might not be required. To this end, the SPARQL 1.1 Graph Store HTTP Protocol provides means to perform certain operations to manage collections of graphs directly via HTTP operations.

For instance, the first part of the update request in Section 4 above is a simple insertion of triples into an RDF graph. On a service supporting this protocol, such insertion can - instead of via a SPARQL 1.1 update request - directly be performed via an HTTP POST operation taking the RDF triples to be inserted as payload:

Other direct HTTP operations for modifying (e.g. to use HTTP PUT to replace an entire graph, or HTTP DELETE to drop an RDF graph) or retrieving (via HTTP GET) RDF graphs are described in the SPARQL 1.1 Graph Store HTTP Protocol specification, which can be viewed as a lightweight alternative to the SPARQL 1.1 protocol in combination with the full SPARQL 1.1 Query and SPARQL 1.1 Update languages.

10 Acknowledgements

The members of the W3C SPARQL Working group who actively contributed to the SPARQL 1.1 specifications are: