SPARQL 1.2 Protocol

Abstract

The SPARQL Protocol and RDF Query Language (SPARQL) is a query language and protocol for RDF. This document specifies the SPARQL Protocol; it describes a means for conveying SPARQL queries and updates to a SPARQL processing service and returning the results via HTTP to the entity that requested them. This protocol was developed by the W3C SPARQL Working Group, part of the Semantic Web Activity as described in the activity statement .

SPARQL Protocol Operations

The SPARQL Protocol consists of two operations: query and update. A protocol operation defines combinations of:

The HTTP method by which the request is sent.
The HTTP query string parameters included in the HTTP request URI.
The message content included in the HTTP request body.
The message content included in the HTTP response body.

The SPARQL 1.2 Protocol is built on top of HTTP. All HTTP requirements for requests and responses must be followed.

Query Operation

The query operation is used to send a SPARQL query to a service and receive the results of the query. The query operation MUST be invoked with either the HTTP GET or HTTP POST method. Client requests for this operation must include exactly one SPARQL query string (parameter name: query) and may include zero or more default graph URIs (parameter name: default-graph-uri) and named graph URIs (parameter name: named-graph-uri). The response to a query request is either the [[[SPARQL12-RESULTS-XML]]], the [[[SPARQL12-RESULTS-JSON]]], the [[[SPARQL12-RESULTS-CSV-TSV]]], or an RDF serialization, depending on the query form and content negotiation [[RFC9110]].

	HTTP Method	Query String Parameters	Request Content Type	Request Message Body
query via GET	GET	`query` (exactly 1) `default-graph-uri` (0 or more) `named-graph-uri` (0 or more)	None	None
query via URL-encoded POST	POST	None	`application/x-www-form-urlencoded`	URL-encoded, ampersand-separated query parameters. `query` (exactly 1) `default-graph-uri` (0 or more) `named-graph-uri` (0 or more)
query via POST directly	POST	`default-graph-uri` (0 or more) `named-graph-uri` (0 or more)	`application/sparql-query`	Unencoded SPARQL query string

The query request's parameters must be sent according to one of these three options:

`query` via GET

Protocol clients may send protocol requests via the HTTP GET method. When using the GET method, clients must URL percent encode all parameters and include them as query parameter strings [[RFC3986]] with the names given above.

HTTP query string parameters must be separated with the ampersand (&) character. Clients may include the query string parameters in any order.

The HTTP request MUST NOT include a message body.

`query` via POST with URL-encoded parameters

Protocol clients may send protocol requests via the HTTP POST method by URL encoding the parameters. When using this method, clients must URL percent encode [[RFC3986]] all parameters and include them as parameters within the request body via the application/x-www-form-urlencoded media type with the name given above. Parameters must be separated with the ampersand (&) character. Clients may include the parameters in any order. The content type header of the HTTP request must be set to application/x-www-form-urlencoded.

`query` via POST directly

Protocol clients may send protocol requests via the HTTP POST method by including the query directly and unencoded as the HTTP request message body. When using this approach, clients must include the SPARQL query string, unencoded, and nothing else as the message body of the request. Clients must set the content type header of the HTTP request to application/sparql-query. Clients may include the optional default-graph-uri and named-graph-uri parameters as HTTP query string parameters in the request URI. Note that UTF-8 is the only valid charset here.

Specifying an RDF Dataset

A SPARQL query is executed against an RDF Dataset. The RDF Dataset for a query may be specified either via the default-graph-uri and named-graph-uri parameters in the SPARQL Protocol or in the SPARQL query string using the FROM and FROM NAMED keywords. If different RDF Datasets are specified in both the protocol request and the SPARQL query string, then the SPARQL service must execute the query using the RDF Dataset given in the protocol request.

Note that a service may reject a query with HTTP response code 400 if the service does not allow protocol clients to specify the RDF Dataset.

If an RDF Dataset is not specified in either the protocol request or the SPARQL query string, then implementations may execute the query against an implementation-defined default RDF dataset.

Accepted Response Formats

Protocol clients should use HTTP content negotiation [[RFC9110]] to request response formats that the client can consume. See below for more on potential response formats.

Success Responses

The SPARQL Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [[RFC9110]] for detailed definitions of each status code. While a protocol service should use a 2XX HTTP response code for a successful query, it may choose instead to use a 3XX response code as per HTTP.

The response body of a successful query operation with a 2XX response is either:

a SPARQL Results Document in XML [[SPARQL12-RESULTS-XML]], JSON [[SPARQL12-RESULTS-JSON]], or CSV/TSV [[SPARQL12-RESULTS-CSV-TSV]] format (for SPARQL Query forms SELECT and ASK [[SPARQL12-QUERY]]); or,
an RDF graph [[[RDF12-CONCEPTS]]] serialized, for example, in the [[[RDF12-XML]]], or an equivalent RDF graph serialization, for SPARQL Query forms DESCRIBE and CONSTRUCT [[SPARQL12-QUERY]]).

The content type of the response to a successful query operation must be the media type defined for the format of the response body.

Failure Responses

The HTTP response codes applicable to an unsuccessful query operation include:

400 if the SPARQL query supplied in the request is not a legal sequence of characters in the language defined by the SPARQL grammar; or,
500 if the service fails to execute the query. SPARQL Protocol services may also return a 500 response code if they refuse to execute a query. This response does not indicate whether the server may or may not process a subsequent, identical request or requests.

The response body of a failed query request is implementation defined. Implementations may use HTTP content negotiation to provide human-readable or machine-processable (or both) information about the failed query request.

A protocol service may use other 4XX or 5XX HTTP response codes for other failure conditions, as per HTTP.

Update Operation

The update operation is used to send a SPARQL update request to a service. The update operation must be invoked using the HTTP POST method. Client requests for this operation must include exactly one SPARQL update request string (parameter name: update) and may include zero or more default graph URIs (parameter name: using-graph-uri) and named graph URIs (parameter name: using-named-graph-uri). The response to an update request indicates success or failure of the request via HTTP response status code.

	HTTP Method	Query String Parameters	Request Content Type	Request Message Body
update via URL-encoded POST	POST	None	`application/x-www-form-urlencoded`	URL-encoded, ampersand-separated query parameters. `update` (exactly 1) `using-graph-uri` (0 or more) `using-named-graph-uri` (0 or more)
update via POST directly	POST	`using-graph-uri` (0 or more) `using-named-graph-uri` (0 or more)	`application/sparql-update`	Unencoded SPARQL update request string

The update request's parameters must be sent according to one of these two options:

`update` via POST with URL-encoded parameters

Protocol clients may send update protocol requests via the HTTP POST method by URL encoding the parameters. When using this approach, clients must URL percent encode all parameters and include them as parameters within the request body via the application/x-www-form-urlencoded media type with the name given above. Parameters must be separated with the ampersand (&) character. Clients may include the parameters in any order. The content type header of the HTTP request must be set to application/x-www-form-urlencoded.

`update` via POST directly

Protocol clients may send update protocol requests via the HTTP POST method by including the update request directly and unencoded as the HTTP request message body. When using this approach, clients must include the SPARQL update request string, unencoded, and nothing else as the message body of the request. Clients must set the content type header of the HTTP request to application/sparql-update. Clients may include the optional using-graph-uri and using-named-graph-uri parameters as HTTP query string parameters in the request URI.

Specifying an RDF Dataset

SPARQL Update requests are executed against a Graph Store, a mutable container of RDF graphs managed by a SPARQL service. The WHERE clause of a SPARQL update DELETE/INSERT operation matches against data in an RDF Dataset, which is a subset of the Graph Store. The RDF Dataset for an update operation may be specified either in the operation string itself using the USING, USING NAMED, and/or WITH keywords, or it may be specified via the using-graph-uri and using-named-graph-uri parameters.

It is an error to supply the using-graph-uri or using-named-graph-uri parameters when using this protocol to convey a SPARQL 1.2 Update request that contains an operation that uses the USING, USING NAMED, or WITH clause.

A SPARQL Update processor should treat each occurrence of the using-graph-uri=g parameter in an update protocol operation as if a USING <g> clause were included for every operation in the SPARQL 1.2 Update request. Similarly, a SPARQL Update processor should treat each occurrence of the using-named-graph-uri=g parameter in an update protocol operation as if a USING NAMED <g> clause were included for every operation in the SPARQL 1.2 Update request.

Success Responses

The SPARQL Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [[RFC9110]] for detailed definitions of each status code. While a protocol service should use a 2XX HTTP response code for an update request that is successfully processed, it may choose instead to use a 3XX response code as per HTTP.

The response body of a successful update request is implementation defined. Implementations may use HTTP content negotiation to provide both human-readable and machine-processable information about the completed update request.

Failure Responses

The HTTP response code for an unsuccessful update request should be:

400 if the SPARQL update request string is not a legal sequence of characters in the language defined by the SPARQL Update grammar; or,
500 if the service fails to execute the update request. SPARQL Protocol services may also return a 500 response code if they refuse to execute an update request. This response does not indicate whether the server may or may not process a subsequent, identical request or requests.

The response body of a failed update request is implementation defined. Implementations may use HTTP content negotiation to provide human-readable or machine-processable (or both) information about the failed update request.

A protocol service may use other 4XX or 5XX HTTP response codes for other failure conditions, as per HTTP.

Determining the Base IRI

The BASE keyword in a SPARQL query or a SPARQL update request string defines the Base IRI used to resolve relative IRIs per [[[RFC3986]]] section 5.1.1, "Base URI Embedded in Content". The SPARQL Protocol does not dereference query URIs so section 5.1.3 does not apply. Finally, per section 5.1.4, SPARQL Protocol services must define their own base URI, which may be the service endpoint.

Example SPARQL Protocol Requests (informative)

The following HTTP trace examples illustrate invocation of the query and update operations under several different scenarios. Some example traces are abstracted from complete HTTP traces in these ways:

In some examples the string "EncodedQuery" represents the URL-encoded string equivalent of the SPARQL query string given in the example; the string "UnencodedQuery" represents the exact SPARQL query string given in the example without any encoding.
For query operation examples, only partial response bodies, containing the query results, are displayed.

Examples of SPARQL Query

SELECT with service-supplied RDF Dataset

This SPARQL query

PREFIX dc: <http://purl.org/dc/elements/1.1/> 
SELECT ?book ?who 
WHERE { ?book dc:creator ?who }

is conveyed via HTTP GET to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=PREFIX%20dc%3A%20%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F%3E%20%0ASELECT%20%3Fbook%20%3Fwho%20%0AWHERE%20%7B%20%3Fbook%20dc%3Acreator%20%3Fwho%20%7D%0A HTTP/1.1
Host: www.example
User-agent: my-sparql-client/0.1

That query against the service-supplied RDF Dataset, executed by that SPARQL query service, returns the following query result:

HTTP/1.1 200 OK
Date: Fri, 06 May 2005 20:55:12 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">

 <head>
   <variable name="book"/>
   <variable name="who"/>
 </head>
 <results>
   <result>
     <binding name="book"><uri>http://www.example/book/book5</uri></binding>
     <binding name="who"><bnode>r29392923r2922</bnode></binding>
   </result>
...
</sparql>

SELECT with simple RDF Dataset

This SPARQL query

PREFIX dc: <http://purl.org/dc/elements/1.1/> 
SELECT ?book ?who 
WHERE { ?book dc:creator ?who }

is conveyed to the SPARQL query service, /http://www.other.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=PREFIX%20dc%3A%20%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F%3E%20%0ASELECT%20%3Fbook%20%3Fwho%20%0AWHERE%20%7B%20%3Fbook%20dc%3Acreator%20%3Fwho%20%7D%0A&default-graph-uri=http%3A%2F%2Fwww.other.example%2Fbooks HTTP/1.1
Host: www.other.example
User-agent: my-sparql-client/0.1

That query — against the RDF Dataset identified by the value of the default-graph-uri parameter, /http://www.other.example/books — executed by that SPARQL query service, returns the following query result:

HTTP/1.1 200 OK
Date: Fri, 06 May 2005 20:55:12 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
 <head>
   <variable name="book"/>
   <variable name="who"/>
 </head>
...
</sparql>

CONSTRUCT with simple RDF dataset and HTTP content negotiation

This SPARQL query

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX myfoaf: <http://www.example/jose/foaf.rdf#>

CONSTRUCT { myfoaf:jose foaf:depiction <http://www.example/jose/jose.jpg>.
            myfoaf:jose foaf:schoolHomepage <http://www.edu.example/>.
            ?s ?p ?o.}
WHERE { ?s ?p ?o. myfoaf:jose foaf:nick "Jo".
       FILTER ( ! (?s = myfoaf:kendall && ?p = foaf:knows && ?o = myfoaf:edd ) 
              && ! ( ?s = myfoaf:julia && ?p = foaf:mbox && ?o = <mailto:julia@mail.example> )
              && ! ( ?s = myfoaf:julia && ?p = rdf:type && ?o = foaf:Person))
}

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fjose-foaf.rdf HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
Accept: text/turtle, application/rdf+xml

With the response illustrated here:

HTTP/1.1 200 OK
Date: Fri, 06 May 2005 20:55:11 GMT
Server: Apache/1.3.29 (Unix)
Connection: close
Content-Type: text/turtle

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX myfoaf: <http://www.example/jose/foaf.rdf#>

myfoaf:jose foaf:name "Jose Jimeñez";
            foaf:depiction <http://www.example/jose/jose.jpg>;
            foaf:nick "Jo";
...

ASK with simple RDF Dataset

This SPARQL query

PREFIX dc: <http://purl.org/dc/elements/1.1/> 
ASK WHERE { ?book dc:creator "J.K. Rowling"}

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fbooks HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1

With the response illustrated here:

HTTP/1.1 200 OK
Date: Fri, 06 May 2005 20:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
 <head></head>
 <boolean>true</boolean>
</sparql>

DESCRIBE with simple RDF Dataset

This SPARQL query

PREFIX books: <http://www.example/book/>
DESCRIBE books:book6

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated here:

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fbooks HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1

With the response illustrated here:

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type:  application/rdf+xml

<?xml version="1.0"?>
<rdf:RDF 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:books="http://www.example/book/"
    xmlns:dc="http://purl.org/dc/elements/1.1/" >
  <rdf:Description rdf:about="http://www.example/book/book6">
    <dc:title>Example Book #6 </dc:title>
  </rdf:Description>
</rdf:RDF>

SELECT with complex RDF Dataset

This SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT ?who ?g ?mbox
WHERE {  ?g dc:publisher ?who .
   GRAPH ?g { ?x foaf:mbox ?mbox }
}

is conveyed to the SPARQL query service, http://www.example/sparql/, as illustrated here (with line breaks for legibility):

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fpublishers
&default-graph-uri=http%3A%2F%2Fwww.example%2Fmorepublishers&named-graph-uri=http%3A%2F%2Fyour.example%2Ffoaf-alice
&named-graph-uri=http%3A%2F%2Fwww.example%2Ffoaf-bob&named-graph-uri=http%3A%2F%2Fwww.example%2Ffoaf-susan
&named-graph-uri=http%3A%2F%2Fthis.example%2Fjohn%2Ffoaf
Host: www.example
User-agent: sparql-client/0.1

With the response illustrated here:

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type:  application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
  <head>
    <variable name="who"/>
    <variable name="g"/>
    <variable name="mbox"/>
  </head>
...
</sparql>

SELECT with query-only RDF Dataset

This SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT ?who ?g ?mbox
FROM <http://www.example/publishers>
FROM NAMED <http://www.example/alice>
FROM NAMED <http://www.example/bob>
WHERE { ?g dc:publisher ?who .
        GRAPH ?g { ?x foaf:mbox ?mbox }
}

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=EncodedQuery HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1

With the response illustrated here:

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
...
</sparql>

SELECT with ambiguous RDF Dataset

This SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT ?who ?g ?mbox
FROM <http://www.example/publishers>
FROM NAMED <http://www.example/john>
FROM NAMED <http://www.example/susan>
WHERE { ?g dc:publisher ?who .
        GRAPH ?g { ?x foaf:mbox ?mbox }
}

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fmorepublishers
&named-graph-uri=http%3A%2F%2Fwww.example%2Fbob&named-graph-uri=http%3A%2F%2Fwww.example%2Falice HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1

This protocol operation contains an ambiguous RDF Dataset: the dataset specified in the query is different than the one specified in the protocol (by way of default-graph-uri and named-graph-uri parameters). A conformant SPARQL Protocol service must resolve this ambiguity by executing the query against the RDF Dataset specified in the protocol:

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
  <head>
    <variable name="who"/>
    <variable name="g"/>
    <variable name="mbox"/>
  </head>
  <results>
    <result>
      <binding name="who">
        <literal>Bob Hacker</literal>
      </binding>
      <binding name="g">
        <uri>http://www.example/bob</uri>
      </binding>
      <binding name="mbox">
        <uri>mailto:bob@oldcorp.example</uri>
      </binding>
    </result>
    <result>
      <binding name="who">
        <literal>Alice Hacker</literal>
      </binding>
      <binding name="g">
        <uri>http://www.example/alice</uri>
      </binding>
      <binding name="mbox">
        <uri>mailto:alice@work.example</uri>
      </binding>
    </result>
  </results>
</sparql>

SELECT with malformed query fault

This syntactically invalid SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name
ORDER BY ?name }

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fmorepublishers HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1

With the error response illustrated here:

HTTP/1.1 400 Bad Request
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: text/plain; charset=UTF-8

4:syntax error, unexpected ORDER, expecting '}'

SELECT with query request refused fault

This SPARQL query

PREFIX bio: <http://bio.example/schema/#>
SELECT ?valence
FROM <http://another.example/protein-db.rdf>
WHERE { ?x bio:protein ?valence }
ORDER BY ?valence

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fanother.example%2Fprotein-db.rdf HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1

With the error response illustrated here:

HTTP/1.1 500 Internal Server Error
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: text/plain

SPARQL Processing Service: Query Request Refused

Your request could not be processed because http://another.example/protein-db.rdf
could not be retrieved within the time alloted.

Long SELECT query using POST with URL encoding

Some SPARQL queries, perhaps machine generated, may be longer than can be reliably conveyed by way of the HTTP GET binding described in 2.1.1 query via GET. In those cases the POST binding described in 2.1.2 query via POST with URL-encoded parameters may be used. This SPARQL query

PREFIX : <http://www.w3.org/2002/12/cal/icaltzd#>
PREFIX Chi: <http://www.w3.org/2002/12/cal/test/Chiefs.ics#>
PREFIX New: <http://www.w3.org/2002/12/cal/tzd/America/New_York#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?summary
WHERE {
    {
        Chi:D603E2AC-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-09-08T16:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:09:27Z"^^xsd:dateTime;
         :dtstart "2002-09-08T13:00:00"^^New:tz;
         :summary ?summary;
         :uid "D603E2AC-C1C9-11D6-9446-003065F198AC" .
        }
        UNION
    {
        Chi:D603E90B-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-09-15T16:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:10:19Z"^^xsd:dateTime;
         :dtstart "2002-09-15T13:00:00"^^New:tz;
         :summary ?summary;
         :uid "D603E90B-C1C9-11D6-9446-003065F198AC" .
        }
        UNION
    {
        Chi:D603ED6E-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-09-22T16:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:11:05Z"^^xsd:dateTime;
         :dtstart "2002-09-22T13:00:00"^^New:tz;
         :summary ?summary;
         :uid "D603ED6E-C1C9-11D6-9446-003065F198AC" .
        }
        UNION
    {
        Chi:D603F18C-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-09-29T16:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:15:46Z"^^xsd:dateTime;
         :dtstart "2002-09-29T13:00:00"^^New:tz;
         :summary ?summary;
         :uid "D603F18C-C1C9-11D6-9446-003065F198AC" .
        }
        UNION
    {
        Chi:D603F5B7-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-11-04"^^xsd:date;
         :dtstamp "2002-09-06T03:12:53Z"^^xsd:dateTime;
         :dtstart "2002-11-03"^^xsd:date;
         :summary ?summary;
         :uid "D603F5B7-C1C9-11D6-9446-003065F198AC" .
        }
        UNION
    {
        Chi:D603F9D7-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-11-10T20:15:00"^^New:tz;
         :dtstamp "2002-09-06T03:14:12Z"^^xsd:dateTime;
         :dtstart "2002-11-10T17:15:00"^^New:tz;
         :summary ?summary;
         :uid "D603F9D7-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D604022C-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-11-17T17:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:14:51Z"^^xsd:dateTime;
         :dtstart "2002-11-17T14:00:00"^^New:tz;
         :summary ?summary;
         :uid "D604022C-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D604065C-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-10-06T19:05:00"^^New:tz;
         :dtstamp "2002-09-06T03:16:54Z"^^xsd:dateTime;
         :dtstart "2002-10-06T16:05:00"^^New:tz;
         :summary ?summary;
         :uid "D604065C-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6040A7E-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-10-13T19:15:00"^^New:tz;
         :dtstamp "2002-09-06T03:17:51Z"^^xsd:dateTime;
         :dtstart "2002-10-13T16:15:00"^^New:tz;
         :summary ?summary;
         :uid "D6040A7E-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6040E96-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-10-20T16:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:18:32Z"^^xsd:dateTime;
         :dtstart "2002-10-20T13:00:00"^^New:tz;
         :summary ?summary;
         :uid "D6040E96-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6041270-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-10-27T17:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:19:15Z"^^xsd:dateTime;
         :dtstart "2002-10-27T14:00:00"^^New:tz;
         :summary ?summary;
         :uid "D6041270-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6041673-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-11-24T20:05:00"^^New:tz;
         :dtstamp "2002-09-06T03:22:09Z"^^xsd:dateTime;
         :dtstart "2002-11-24T17:05:00"^^New:tz;
         :summary ?summary;
         :uid "D6041673-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6041A73-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-12-01T17:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:22:52Z"^^xsd:dateTime;
         :dtstart "2002-12-01T14:00:00"^^New:tz;
         :summary ?summary;
         :uid "D6041A73-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D60421EF-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-12-08T17:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:24:04Z"^^xsd:dateTime;
         :dtstart "2002-12-08T14:00:00"^^New:tz;
         :summary ?summary;
         :uid "D60421EF-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6042660-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-12-15T20:05:00"^^New:tz;
         :dtstamp "2002-09-06T03:25:03Z"^^xsd:dateTime;
         :dtstart "2002-12-15T17:05:00"^^New:tz;
         :summary ?summary;
         :uid "D6042660-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6042A93-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-12-22T17:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:25:47Z"^^xsd:dateTime;
         :dtstart "2002-12-22T14:00:00"^^New:tz;
         :summary ?summary;
         :uid "D6042A93-C1C9-11D6-9446-003065F198AC" .
    }
        UNION
    {
        Chi:D6042EDF-C1C9-11D6-9446-003065F198AC     a :Vevent;
         :dtend "2002-12-28T21:00:00"^^New:tz;
         :dtstamp "2002-09-06T03:26:51Z"^^xsd:dateTime;
         :dtstart "2002-12-28T18:00:00"^^New:tz;
         :summary ?summary;
         :uid "D6042EDF-C1C9-11D6-9446-003065F198AC" .
    }
}

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

POST /sparql/ HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 9461

query=EncodedQuery&default-graph-uri=http%3A%2F%2Fanother.example%2Fcalendar.rdf

With the response illustrated here:

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
    <head>
        <variable name="summary"/>
    </head>
    <results>
        <result>
            <binding name="summary">
                <literal>Chiefs vs. Cleveland @ Cleveland Stadium</literal>
            </binding>
        </result>
        <result>
            <binding name="summary">
                <literal>Chiefs vs. Jacksonville @ Arrowhead Stadium</literal>
            </binding>
        </result>
        <result>
            <binding name="summary">
                <literal>Chiefs vs. New England @ Gillette Stadium</literal>
            </binding>
        </result>
        ...
        <result>
            <binding name="summary">
                <literal>Chiefs vs. Oakland @ Network Associates Coliseum</literal>
            </binding>
        </result>
    </results>
</sparql>

Long SELECT query using direct POST

SPARQL queries may also be POSTed directly without URL encoding, as described in 2.1.3 query via POST directly. The same query used in the previous example is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

POST /sparql/?default-graph-uri=http%3A%2F%2Fanother.example%2Fcalendar.rdf HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
Content-Type: application/sparql-query

UnencodedQuery

With the same response as in the previous example.

SELECT with internationalization

SPARQL queries may include internationalized characters or character sets. This SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX 食: <http://www.w3.org/2001/sw/DataAccess/tests/data/i18n/kanji.ttl#>
SELECT ?name ?food 
WHERE { [ foaf:name ?name ; 食:食べる ?food ] . }

is conveyed to the SPARQL query service, /http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=PREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0APREFIX%20%E9%A3%9F%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2001%2Fsw%2FDataAccess%2Ftests%2Fdata%2Fi18n%2Fkanji.ttl%23%3E%0ASELECT%20%3Fname%20%3Ffood%20%0AWHERE%20%7B%20%5B%20foaf%3Aname%20%3Fname%20%3B%20%E9%A3%9F%3A%E9%A3%9F%E3%81%B9%E3%82%8B%20%3Ffood%20%5D%20.%20%7D
Host: www.example
User-agent: sparql-client/0.1

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix)
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
...
</sparql>

SELECT with reified triple patterns

SPARQL queries can target reified triples. This SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX ex: <http://example.org/>
SELECT ?name ?person
WHERE { << _:a foaf:name ?name >> ex:statedBy ?person . }

is conveyed to the SPARQL query service, http://www.example/sparql/, as illustrated in this HTTP trace:

GET /sparql/?query=PREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0APREFIX%20ex%3A%20%3Chttp%3A%2F%2Fexample.org%2F%3E%0ASELECT%20%3Fname%20%3Fperson%0AWHERE%20%7B%20%3C%3C%28%20_%3Aa%20foaf%3Aname%20%3Fname%20%29%3E%3E%20ex%3AstatedBy%20%3Fperson%20.%20%7D
Host: www.example
User-agent: sparql-client/0.1

HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix)
Connection: close
Content-Type: application/sparql-results+xml

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
...
</sparql>

Examples of SPARQL Update

UPDATE using URL-encoded parameters

An example request, which is a serialisation of a request sent to http://localhost:8888/test for the query INSERT DATA { <a> <p> <b> } is shown below using the URL-encoded parameter form.

POST /test HTTP/1.1
Host: localhost:8888
Accept: text/plain
Content-Length: 62
Content-Type: application/x-www-form-urlencoded

update=INSERT%20DATA%20%7B%20%3Ca%3E%20%3Cp%3E%20%3Cb%3E%20%7D

UPDATE using POST directly

Update requests may be sent as a POST request with a Content-Type of application/sparql-update:

POST /test HTTP/1.1
Host: localhost:8888
Accept: */*
Content-Type: application/sparql-update
Content-Length: 27

INSERT DATA { <a> <p> <b> }

UPDATE specifying dataset and using POST directly

A dataset for an update request may be specified using the using-graph-uri and using-named-graph-uri parameters. The serialisation of an example request sent to http://localhost:8888/test and specifying a dataset with default graph http://localhost:8888/people is shown below.

POST /test?using-graph-uri=http%3A%2F%2Flocalhost%3A8888%2Fpeople HTTP/1.1
Host: localhost:8888
Accept: */*
Content-Type: application/sparql-update
Content-Length: 136

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
DELETE { ?person ?property ?value }
WHERE { ?person ?property ?value ; foaf:givenName 'Fred' }

Multi-operation UPDATE using URL-encoded parameters

A sequence of multiple operations may be included in a single request, separated by a ';' (semicolon). The serialisation of an example request sent to http://localhost:8888/test for the query

DELETE DATA { <a> <p> <old> } ;
INSERT DATA { <a> <p> <new> }

is shown below using the URL-encoded parameter form.

POST /test HTTP/1.1
Host: localhost:8888
Accept: */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 130

update=DELETE%20DATA%20%7B%20%3Ca%3E%20%3Cp%3E%20%3Cold%3E%20%7D%20%3B%0AINSERT%20DATA%20%7B%20%3Ca%3E%20%3Cp%3E%20%3Cnew%3E%20%7D

Multi-operation UPDATE specifying dataset and using URL-encoded parameters

When POSTing an update request with URL-encoded parameters, the dataset parameters using-graph-uri and using-named-graph-uri are specified in the POST body with the serialized request. The serialisation of an example request sent to http://localhost:8888/test for the query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
INSERT { GRAPH <http://localhost:8888/people> { ?person ?property ?value } }
WHERE { GRAPH ?g { ?person ?property ?value ; foaf:givenName 'Fred' } }

and specifying a dataset with the named graphs http://localhost:8888/alice/foaf.rdf and http://localhost:8888/eve/foaf.rdf is shown below.

POST /test HTTP/1.1
Host: localhost:8888
Accept: */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 130

using-named-graph-uri=http%3A%2F%2Flocalhost%3A8888%2Falice%2Ffoaf.rdf&using-named-graph-uri=http%3A%2F%2Flocalhost%3A8888%2Feve%2Ffoaf.rdf&update=PREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0AINSERT%20%7B%20GRAPH%20%3Chttp%3A%2F%2Flocalhost%3A8888%2Fpeople%3E%20%7B%20%3Fperson%20%3Fproperty%20%3Fvalue%20%7D%20%7D%0AWHERE%20%7B%20GRAPH%20%3Fg%20%7B%20%3Fperson%20%3Fproperty%20%3Fvalue%20%3B%20foaf%3AgivenName%20%27Fred%27%20%7D%20%7D

Multi-operation UPDATE specifying dataset and using POST directly

The serialisation of an example request sent to http://localhost:8888/test and specifying a dataset with the named graphs http://localhost:8888/alice/foaf.rdf and http://localhost:8888/eve/foaf.rdf is shown below.

POST /test?using-named-graph-uri=http%3A%2F%2Flocalhost%3A8888%2Falice%2Ffoaf.rdf&using-named-graph-uri=http%3A%2F%2Flocalhost%3A8888%2Feve%2Ffoaf.rdf HTTP/1.1
Host: localhost:8888
Accept: */*
Content-Type: application/sparql-update
Content-Length: 190

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
INSERT { GRAPH <http://localhost:8888/people> { ?person ?property ?value } }
WHERE { GRAPH ?g { ?person ?property ?value ; foaf:givenName 'Fred' } }

Abstract

Introduction

Document Conventions

Terminology

SPARQL Protocol Operations

Query Operation

query via GET

query via POST with URL-encoded parameters

query via POST directly

Specifying an RDF Dataset

Accepted Response Formats

Success Responses

Failure Responses

Update Operation

update via POST with URL-encoded parameters

update via POST directly

Specifying an RDF Dataset

Success Responses

Failure Responses

Determining the Base IRI

Example SPARQL Protocol Requests (informative)

Examples of SPARQL Query

SELECT with service-supplied RDF Dataset

SELECT with simple RDF Dataset

CONSTRUCT with simple RDF dataset and HTTP content negotiation

ASK with simple RDF Dataset

DESCRIBE with simple RDF Dataset

SELECT with complex RDF Dataset

SELECT with query-only RDF Dataset

SELECT with ambiguous RDF Dataset

SELECT with malformed query fault

SELECT with query request refused fault

Long SELECT query using POST with URL encoding

Long SELECT query using direct POST

SELECT with internationalization

SELECT with reified triple patterns

Examples of SPARQL Update

UPDATE using URL-encoded parameters

UPDATE using POST directly

UPDATE specifying dataset and using POST directly

Multi-operation UPDATE using URL-encoded parameters

Multi-operation UPDATE specifying dataset and using URL-encoded parameters

Multi-operation UPDATE specifying dataset and using POST directly

Policy Considerations

Security

Conformance

Changes between SPARQL 1.1 Protocol and SPARQL 1.2 Protocol

Changes between SPARQL 1.0 Protocol and SPARQL 1.1 Protocol

Privacy Considerations

Security Considerations

Internationalization Considerations

`query` via GET

`query` via POST with URL-encoded parameters

`query` via POST directly

`update` via POST with URL-encoded parameters

`update` via POST directly