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 is an Editors' Working Draft.
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.19 2009/10/21 01:52:56 lfeigenb fixed link Revision 1.18 2009/10/21 01:37:45 lfeigenb more pubrules prep Revision 1.17 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
