lt,
gt,
apos,
quot">
MAY">
]>
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 .
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/.
This document is a Last Call Working Draft. Publication as a Last Call Working Draft indicates that the SPARQL Working Group believes it has addressed all substantive issues and that the document is stable. The Working Group expects to advance this specification to Recommendation Status.
The end date of the Last Call review period is 02 February 2012, i.e., comments on this working draft are due on or before this date.
The set of SPARQL documents comprises:
Comments on this document should be sent to public-rdf-dawg-comments@w3.org, a mailing list with a public archive. Questions and comments about SPARQL that are not related to this specification, including extensions and features, can be discussed on the mailing list public-sparql-dev@w3.org, (public archive).
This document was produced by the SPARQL Working Group, which is part of the W3C Semantic Web Activity.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Significant changes since the previously published Working Draft are:
@@@ World-Wide Web Consortium, SPARQL Working Group, 2009.
Created in electronic form.
$Id: Overview.xml,v 1.46 2013-03-20 18:07:45 sandro Exp $
This document describes the SPARQL 1.1 Protocol, a means of conveying SPARQL queries and updates from clients to SPARQL processors. The SPARQL Protocol has been designed for compatibility with the SPARQL 1.1 Query Language [SPARQL] and with the SPARQL 1.1 Update Language for RDF. This document is primarily intended for software developers interested in implementing SPARQL query and update services and clients.
The SPARQL Protocol consists of two HTTP operations: a query operation for performing SPARQL Query Language queries and an update operation for performing SPARQL Update Language requests. SPARQL Protocol clients send HTTP requests to SPARQL Protocol services that handle the request and send HTTP responses back to the originating client.
A separate document describes the SPARQL 1.1 Graph Store HTTP Protocol which describes the use of HTTP operations for the purpose of managing a collection of graphs in the REST architectural style.
When this document uses the words must, must not, should, should not, may and recommended, and the words appear as emphasized text, they must be interpreted as described in RFC 2119 [RFC2119].
The SPARQL Protocol consists of two operations: query and update. A protocol operation defines combinations of:
The SPARQL 1.1 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 SPARQL XML Results
Format, the SPARQL JSON Results Format, the SPARQL CSV/TSV Results Format, or an RDF
serialization, depending on the query form [SPARQL] and content
negotiation [RFC2616].
| 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 with the names given above [RFC3986].
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.
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.
Protocol clients should use HTTP content negotiation [RFC2616] to request response formats that the client can consume. See below for more on potential response formats.
The SPARQL Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [RFC2616] 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:
The content type of the response to a successful query operation must be the media type defined for the format of the response body.
The HTTP response codes applicable to an unsuccessful query operation include:
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 [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.
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.
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 [UPDATE]
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.1 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.1
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.1 Update request.
The SPARQL Protocol uses the response status codes defined in HTTP to indicate the success or failure of an operation. Consult the HTTP specification [RFC2616] 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.
The HTTP response code for an unsuccessful update request should be:
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.
The BASE keyword in a SPARQL query or a SPARQL
update request string defines the Base IRI used to resolve relative
IRIs per Uniform
Resource Identifier (URI): Generic Syntax [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.
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:
query operation examples, only partial response bodies, containing the query results, are displayed.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>
...
<result>
<binding name="book"><uri>http://www.example/book/book6</uri></binding>
<binding name="who"><bnode>r8484882r49593</bnode></binding>
</result>
</results>
</sparql>
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>
...
<results>
<result>
<binding name="book"><uri>http://www.example/book/book2</uri></binding>
<binding name="who"><bnode>r1115396427r1133</bnode></binding>
</result>
<result>
<binding name="book"><uri>http://www.example/book/book3</uri></binding>
<binding name="who"><bnode>r1115396427r1133</bnode></binding>
</result>
<result>
<binding name="book"><uri>http://www.example/book/book1</uri></binding>
<binding name="who"><literal>J.K. Rowling</literal></binding>
</result>
</results>
</sparql>
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";
...
foaf:schoolHomepage <http://www.edu.example/>;
foaf:workplaceHomepage <http://www.corp.example/>;
foaf:homepage <http://www.example/jose/>;
foaf:knows myfoaf:juan;
rdf:type foaf:Person.
myfoaf:juan foaf:mbox <mailto:juan@mail.example>;
rdf:type foaf:Person.
Note: registration for the media type text/turtle was started but not completed at the time of this publication. Please see http://www.w3.org/TR/turtle for the final registered media type for the Turtle language.
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>
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>
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>
...
<results>
<result>
<binding name="who">
<literal>Alice</literal>
</binding>
<binding name="g">
<uri>http://your.example/foaf-alice</uri>
</binding>
<binding name="mbox">
<uri>mailto:alice@example.org</uri>
</binding>
</result>
<result>
<binding name="who">
<literal>Bob</literal>
</binding>
<binding name="g">
<uri>http://www.example/foaf-bob</uri>
</binding>
<binding name="mbox">
<uri>mailto:bob@work.example</uri>
</binding>
</result>
<result>
<binding name="who">
<literal>Susan</literal>
</binding>
<binding name="g">
<uri>http://www.example/foaf-susan</uri>
</binding>
<binding name="mbox">
<uri>mailto:susan@work.example</uri>
</binding>
</result>
<result>
<binding name="who">
<literal>John</literal>
</binding>
<binding name="g">
<uri>http://this.example/john/foaf</uri>
</binding>
<binding name="mbox">
<uri>mailto:john@home.example</uri>
</binding>
</result>
</results>
</sparql>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#">
...
<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>
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>
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 '}'
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.
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. Miami @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>BYE</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. San Francisco @ 49ers Stadium at Candlestick Point</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Buffalo @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. NY Jets @ Giants Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. San Diego @ Qualcomm Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Denver @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Oakland @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Seattle @ Seahawks Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Arizona @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. St. Louis @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Denver @ INVESCO Field at Mile High</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. San Diego @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Oakland @ Network Associates Coliseum</literal>
</binding>
</result>
</results>
</sparql>
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.
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>
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 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> }
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' }
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
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
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' } }
There are at least two possible sources of denial-of-service attacks against SPARQL protocol services. First, under-constrained queries can result in very large numbers of results, which may require large expenditures of computing resources to process, assemble, or return. Another possible source are queries containing very complex — either because of resource size, the number of resources to be retrieved, or a combination of size and number — RDF Dataset descriptions, which the service may be unable to assemble without significant expenditure of resources, including bandwidth, CPU, or secondary storage. In some cases such expenditures may effectively constitute a denial-of-service attack. A SPARQL protocol service may place restrictions on the resources that it retrieves or on the rate at which external resources are retrieved. There may be other sources of denial-of-service attacks against SPARQL query processing services.
Since a SPARQL protocol service may make HTTP requests of other origin servers on behalf of its clients, it may be used as a vector of attacks against other sites or services. Thus, SPARQL protocol services may effectively act as proxies for third-party clients. Such services may place restrictions on the resources that they retrieve or on the rate at which external resources can be retrieved. SPARQL protocol services may log client requests in such a way as to facilitate tracing them with regard to third-party origin servers or services.
SPARQL protocol services may choose to detect these and other costly, or otherwise unsafe, queries, impose time or memory limits on queries, or impose other restrictions to reduce the service's (and other service's) vulnerability to denial-of-service attacks. They also may refuse to process such query requests.
SPARQL protocol services may remove, insert, and change underlying data via the update operation. To protect against malicious or destructive updates, implementations may choose not to implement the update operation. Alternatively, implementations may choose to use HTTP authentication mechanisms or other implementation-defined mechanisms to prevent unauthorized invocations of the update operation.
Different IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Users of SPARQL must take care to construct queries with IRIs that match the IRIs in the data. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
The status of the parts of SPARQL 1.1 Protocol (this document) is as follows:
A conformant SPARQL Protocol service:
query operation or the update operation in the way described in this document ("SPARQL 1.1 Protocol");query and update operations;This specification extends and updates the SPARQL Protocol for RDF of January, 2008. The significant changes are:
$Log: Overview.xml,v $ Revision 1.46 2013-03-20 18:07:45 sandro added None changelog for PR Revision 1.45 2013-01-27 17:37:45 sandro add changelog entry Revision 1.44 2012-12-07 18:52:45 gwilliam Fixed typo when referencing the application/x-www-form-urlencoded media type. Revision 1.43 2012/11/07 05:46:43 gwilliam Removed Accept header from error example in section 3.1.10 (SELECT with query request refused fault). Revision 1.42 2012/11/07 02:20:45 sandro various little fixes to references and links for publication Revision 1.41 2012/11/06 04:03:21 sandro mark cvs log for auto deletion Revision 1.40 2012/10/02 14:11:39 gwilliam Changed error example to use text/plain instead of text/html. Revision 1.39 2012/09/25 16:10:23 gwilliam Reverted use of custom http status messages in error examples. Revision 1.38 2012/09/04 15:43:08 gwilliam Added missing text about response to failed query operations being implementation-defined. Revision 1.37 2012/06/19 14:40:02 gwilliam Use better http status messages in error traces. Updated link to 1.1 Update to point at /TR/. Revision 1.36 2012/01/03 17:57:14 gwilliam Updated status section boilerplate. Removed tbody markup in table to make W3C validator happy. Fixed broken link fragment id. Revision 1.35 2011/12/19 16:58:50 gwilliam Cleaned up references. Revision 1.34 2011/11/22 15:25:56 lfeigenb remove editorial note in security section Revision 1.33 2011/11/21 21:06:52 lfeigenb fixed small editorial issues; fixed treatment of RDF datasets for protocol update operations Revision 1.32 2011/11/17 14:56:24 lfeigenb updates as per AndyS pre-last call review Revision 1.31 2011/11/15 17:12:25 gwilliam Fixed section number in link text to "Policy Considerations". Revision 1.30 2011/11/15 17:07:31 gwilliam Replaced "EncodedQuery" with actual encoded query string in two examples. Revision 1.29 2011/11/15 17:04:33 gwilliam Properly escape default-graph-uri and named-graph-uri arguments in examples. Revision 1.28 2011/11/15 16:48:30 gwilliam Typo and formatting fixes. Added text restricting response body conditions to 2xx responses. Added text to discuss the *response* to a successful query operation. Added normative rfc2119 language to requirement for setting a base URI. Revision 1.27 2011/11/15 16:14:06 gwilliam "response code 400" -> "HTTP response code 400". Revision 1.26 2011/11/15 16:08:37 gwilliam Removed stray '>'. Revision 1.25 2011/11/15 15:36:23 lfeigenb near final changes pre-last call for protocol Revision 1.24 2011/11/10 00:03:37 gwilliam Added reference links and addressed many todo items. Revision 1.23 2011/09/20 14:15:01 lfeigenb moved overview2.xml to overview.xml Revision 1.9 2011/09/13 16:51:43 gwilliam Added update examples. Fixed URL encoding of default-graph-uri parameter in section #select-longpost-direct. Revision 1.8 2011/09/13 15:04:26 gwilliam Added stubs for more UPDATE examples. Revision 1.7 2011/09/13 14:42:46 gwilliam Added links to other SPARQL 1.1 docs in TR space (not all in place yet). Revision 1.6 2011/09/13 14:30:43 gwilliam Added internal section links in introduction. Revision 1.5 2011/08/06 20:48:31 lfeigenb various improvements per AndyS initial review Revision 1.4 2011/08/02 02:31:57 lfeigenb added direct POST example for query Revision 1.3 2011/04/13 15:58:30 lfeigenb add update operation details Revision 1.2 2011/03/15 20:37:06 lfeigenb updated intro and query operation Revision 1.1 2011/03/01 03:21:34 lfeigenb initial changes from Greg W Revision 1.22 2011/01/24 15:45:33 sharris2 Added examples of PSOT transmission of SPARQL Update requests Revision 1.21 2010/05/13 18:26:19 dcharbon2 remove "graph-does-not-exist" and "graph-already-exists" errors. Revision 1.20 2010/02/12 08:11:16 lfeigenb Updated Kendall Clark's email address. Removed "previous version" editor designation. Revision 1.19 2010/01/27 01:33:33 apollere2 removed cvs-log-meat div2, because it causes a strange TOC entry Revision 1.18 2010/01/26 16:18:42 dcharbon2 Fixed broken fragment references. Revision 1.17 2010/01/22 02:03:03 apollere2 changed the second occurrence of Excerpt-1.3 to Exceprt-1.4 Revision 1.16 2010/01/22 01:56:24 apollere2 Adapted previous versions, dates, etc. Revision 1.15 2010/01/18 21:28:18 dcharbon2 * Fixed name references for protocol and query specifications * Removed references to obsolete update syntax * Updated formatting of MUST and MUST NOT where it was incorrect * Simplified text surrounding reporting debugging data on service fault. * Update section references * Improved xml schema fragment descriptions * Updated the "update" type removing references to dataset types in protocol-types.xsd Revision 1.14 2010/01/10 16:02:56 lfeigenb * Add Query faults back in * Clean up the XX tokens * Editor notes for Update's out and fault messages * Note changes since previous WD in the SotD Revision 1.13 2010/01/05 16:50:46 dcharbon2 Updated URI references for WSDL 2.0. Also updated the Update section for faults. Revision 1.12 2009/10/21 02:25:37 lfeigenb fix links add .wsdl and .xsd Revision 1.10 2009/10/20 20:21:47 lfeigenb fixed placement of table Revision 1.9 2009/10/20 19:10:19 lfeigenb Fixed and added support for markup that was previously unsupported by our XSLTs. Future SPARQL-specific customizations should go in shared/sparql.xsl Revision 1.8 2009/10/20 18:13:47 lfeigenb Factored out shared XML spec files into docs/shared Revision 1.7 2009/10/20 16:24:01 lfeigenb remove extra 1.1 ; DAWG -> SPARQL WG ; add note about security for update Revision 1.6 2009/10/20 05:58:28 lfeigenb Make all changes and updates suggested in http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0204.html Revision 1.5 2009/10/15 22:37:08 lfeigenb Changes in preparation of FPWD as per http://www.w3.org/2009/sparql/meeting/2009-10-13 Revision 1.4 2009/10/03 00:15:20 lfeigenb fixed xml tags Revision 1.3 2009/10/03 00:13:19 lfeigenb Initial updates by SimonKJ Revision 1.2 2009/09/28 22:55:59 eric - some leftover noise from the port Revision 1.1 2009/09/28 22:30:46 eric CREATED