Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
SPARQL provides a standard way to query RDF data. The SPARQL update language allows a user to update RDF graphs in an RDF dataset at various levels of granularity, including individual RDF statements. The protocol described here is meant to provide a minimal set of uniform, colloquial HTTP operations for managing a semantic web of network-manipulable RDF at a strictly large level of granularity.
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 is the First Public Working Draft of the "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs" specification for review by W3C members and other interested parties.
If you wish to make comments regarding this document, please send them to public-rdf-dawg-comments@w3.org (subscribe, archives)
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
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.
The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C SPARQL working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section.
The W3C SPARQL Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track.
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.
This specification describes the use of the HTTP protocol for the purpose of managing named RDF graphs on an HTTP server. It emphasizes a clear separation between the RDF graph management actions performed from the networked body of RDF knowledge identified by a URI as the target of the actions, the lexical form of a Request URI, the URI of a graph in an RDF dataset, and the (optional) RDF delivered with the message. This specification relies on an intuitive interpretation of the underlying HTTP protocol semantics to determine how the RDF graphs are modified. Where the meaning of the operations are described, an SPARQL Update equivalent syntax is shown for clarity.
One of the goals for this specification (from the WG) is to define a RESTful protocol for RDF. However, the editor has chosen to emphasize the tenants of REST as they apply to RDF graph management explicitly rather than use the term RESTful. It is not clear to the editor if the current text does this sufficiently
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 following terminology is used in this document:
In this specification, the phrase "the resolvable URI of a graph" is shorthand for "a URI which, when dereferenced, is expected to produce a RDF graph representation".
This protocol specifies HTTP operations for managing network-manipulable RDF datasets as well as their semantics. In particular, it provides operations for removing, creating, and replacing RDF graphs as well as for adding RDF statements to existing RDF graphs . The HTTP operations defined here use URIs to route native HTTP operations to a network-manipulable RDF dataset.
This protocol does not constrain the form of the URIs that are used. The URI space of each server is controlled by the server.
However, a compliant implementation of this specification MUST accept HTTP requests directed at its dataset that include an RDF/XML payload
It is not clear which of the various RDF notation will be allowed or required as RDF payload in addition to RDF/XML. Other examples include (but are not limited to): RDFa, Turtle, Notation 3, and GRDDL. In the case of the latter (GRDDL) there are also security considerations as well. See: 8. Security considerations
We recall from [SPARQL] that IRIs for RDF graphs in SPARQL queries identify a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph)
Consider the following HTTP request to a server that implements this protocol:
GET http://example.com/rdf-graphs/employees HTTP/1.1 Host: example.com Accept: application/rdf+xml
Per [RFC2616], the most common usage of a Request-URI is to identify a resource on an origin server or gateway. In our example, the URI that follows GET in the request (emphasized in bold text) is meant to identify RDF triples on the example.com server that describe employees. In addition, the request specifies the GET operation, which (intuitively) means that a representation of these triples should be returned. In this case the preferred representation format is application/rdf+xml
In this way, an HTTP request can route operations towards a named graph in an RDF dataset via its URI(s). However, in using URIs in this way, we are not directly identifying the RDF graphs but rather the networked RDF knowledge they represent.
The diagram below attempts to emphasize this distinction and the dotted shapes are in reference to the issue noted below 
The working group has also considered the need to use query components to specify the URI of the graph to manage. (e.g. the
graph keyword in the above example). This would be different from using the Request URI of inbound messages to
directly identify the networked RDF knowledge. Other open questions include: If an HTTP GET request is dispatched to such a URI,
is the assumption that the Request URI refers to a data-producing process rather than some networked RDF knowledge represented
by an RDF graph? Or is the URI considered just another identifier for the same networked RDF knowledge (i.e., an alias)?
This section describes the use of the HTTP verbs to determine the operations performed on Networked RDF knowledge
The HTTP PUT method SHOULD can be used to store the enclosed RDF payload as networked knowledge . It SHOULD be considered a native implementation of the following sequence of SPARQL Update operations
DROP SILENT GRAPH <request_uri>
CREATE SILENT GRAPH <request_uri>
INSERT DATA [ INTO <request_uri> ] { .. RDF payload .. }
This is only necessary if the identified facts do not already exist. Otherwise, the following operation would suffice by itself:
INSERT DATA INTO <request_uri>
{ .. RDF payload .. }
The URI in the request identifies the RDF payload enclosed with the request as networked RDF knowledge. The server MUST NOT attempt to apply the request to some other resource. If the Request-URI refers to already existing RDF knowledge, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to existing RDF knowledge, and that URI is capable of being defined as new networked knowledge by the requesting user agent, the origin server can create the knowledge with that URI in the associated network-manipulable dataset.
The HTTP DELETE method SHOULD be used to delete the RDF knowledge identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
It is equivalent to:
CLEAR [ GRAPH <request_uri> ]
The HTTP POST method SHOULD be used to request that the origin server accept the RDF payload enclosed in the request as a new subordinate of the networked RDF knowledge identified by the Request-URI in the Request-Line. It is designed to allow a uniform method to cover the usecase of providing a block of RDF to a data-handling process for insertion
CREATE [ SILENT ] GRAPH <request_uri>
INSERT [ INTO <request_uri> ] { .. RDF payload .. }
This document describes updating and fetching RDF data from RDF datasets over HTTP in the REST style. It is a companion to the use of SPARQL/Update over the SPARQL protocol which uses HTTP POST to transmit a SPARQL/Update request. Both protocols specify different operations performed via the HTTP POST method.
The HTTP GET method SHOULD be used to retrieve a graph representation of the networked RDF knowledge identified by the Request-URI.
This is equivalent to the following SPARQL query:
CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <request_uri> { ?s ?p /o } }
The semantics of the GET method change to a "conditional GET" depending on the existence of headers indicating constraints on the request. A conditional GET requests that the graph representation be transferred only under the circumstances described by the conditional header field(s) (see [RFC2616] for more information on this ). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.
The response to a GET request on networked RDF knowledge SHOULD be made cacheable wherever possible
@@Additional input is necessary to identify and address possible security considerations
@@Additional input is needed regarding whether specific language (beyond describing the expected behavior) is needed to determine levels of conformance
$Log: Overview.html,v $ Revision 1.5 2018/10/09 13:27:05 denis fix validation of xhtml documents Revision 1.4 2017/10/02 10:39:31 denis add fixup.js to old specs Revision 1.3 2009/10/23 14:16:05 ivan *** empty log message *** Revision 1.2 2009/10/22 07:19:13 ivan *** empty log message *** Revision 1.1 2009/10/21 14:18:34 ivan *** empty log message *** Revision 1.3 2009/10/21 01:52:56 lfeigenb fixed link Revision 1.2 2009/10/21 01:37:45 lfeigenb more pubrules prep Revision 1.1 2009/10/21 01:34:53 lfeigenb pubrules prep Revision 1.16 2009/10/16 20:58:07 cogbuji css validation icon Revision 1.15 2009/10/16 20:56:48 cogbuji more pubrules fixes Revision 1.14 2009/10/16 20:51:32 cogbuji validation icon added to bottom Revision 1.13 2009/10/16 20:49:53 cogbuji move pub-rules fixes (XHTML WFormedness) Revision 1.12 2009/10/16 20:48:44 cogbuji XHTML strict profile fixes Revision 1.11 2009/10/16 20:40:32 cogbuji various pub-rules related fixes Revision 1.10 2009/10/16 20:25:10 cogbuji well-formedness issueas Revision 1.9 2009/10/16 19:54:46 cogbuji added references, fixed a few things Revision 1.8 2009/10/12 16:50:11 cogbuji incorporated comments from DAWG members regarding proxies, and POST semantics Revision 1.7 2009/10/06 16:09:51 cogbuji Updates per feedback from AndyS: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0004.html Revision 1.6 2009/09/29 01:50:43 cogbuji updated model diagram and updated use of terminology Revision 1.5 2009/09/28 22:27:04 cogbuji updated language regarding granularity Revision 1.4 2009/09/28 22:25:29 cogbuji no-op to test log directive
