SPARQL 1.1 Graph Store HTTP Protocol

W3C Working Draft 12 May 2011

This version:
Latest version:
Previous version:
Chimezie Ogbuji, chimezie@gmail.com, Invited Expert


This document describes the use of HTTP operations for the purpose of managing a collection of graphs in the REST architectural style.

Status of This Document

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 a Last Call Working Draft.

The end date of the Last Call review period is 29 July 2011.

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.

Change Summary

The following is a summary of the major changes made from the last publication. The term Network-manipulable Graph Store was replaced with Graph Store. Support for indirect identification of the default graph was added. The behavior of HTTP PATCH was clarified. The retrieval of service descriptions has also been clarified. The status codes expected in response to specific behavior has been expanded. The general behavior of PUT and POST has been clarified. The term 'RDF knowledge' has been replaced with 'RDF graph content.' Graph IRIs specified via query components must be absolute (support for base resolution has been removed). The specification title has been changed to 'SPARQL 1.1 Graph Store HTTP Protocol.' Examples have been made more consistent across the document and more details regarding the actual HTTP messages and responses have been added to them.

No Endorsement

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.

Table of Contents

  1. Introduction
  2. Terminology
  3. Protocol Model
  4. Graph Identification
  5. Graph Management Operations
  6. Security Considerations
  7. References

1 Introduction

This document describes updating and fetching RDF graph content from a Graph Store over HTTP in the REST style [REST]. In doing so, it appeals to the following interface constraints that comprise the REST architectural style:

  1. identification of resources
  2. manipulation of resources through representations
  3. self-descriptive messages

It emphasises the following distinct concepts: RDF graph management action, the RDF graph content identified as the target of the action, the lexical form of a Request URI, the URI of a graph in an Graph Store, and the (optional) RDF delivered with the message. The first REST constraint is met by clarifying what is being identified in the HTTP requests that are supported by this protocol and providing an alternative mechanism for identifying RDF graph content where the URI of the graph cannot be directly used. The second constraint is met by specifying how representations of RDF graphs used as the message body of HTTP requests supported by this protocol manipulate the corresponding RDF graph content. The third constraint is an inherent characteristic of RDF as the framework for a Self-Describing Semantic Web

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.

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].

This document is closely related to the following specifications:

2 Terminology

The following terminology is used in this document:

Implementations of this protocol are HTTP/1.1 servers [RFC2616] MUST interpet request messages as graph management operations on an underlying Graph Store where the subject of the operation is indicated through the use of a Graph IRI.

3 Protocol Model

This protocol specifies the semantics of HTTP operations for managing a Graph Store. In particular, it provides operations for removing, creating, and replacing RDF graph content as well as for adding RDF statements to existing RDF graph content . The interface defined here uses URIs to direct native HTTP operations to an implementation of this protocol which responds by making appropriate modifications to the underlying Graph Store. A compliant implementation of this specification SHOULD accept HTTP requests directed at its Graph Store and handle them as specified by this protocol with the exception of security considerations such as those discussed in section 7 and others (DOS attacks, etc.)

4 Graph Identification

4.1 Direct Graph Identification

We recall from [SPARQL] that IRIs for RDF graphs in SPARQL queries identify a resource, and the resource has a representation that serializes that graph (or, more precisely: by an RDF document of the graph)

Consider the following HTTP request to a server that implements this protocol:

   GET /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 corresponding request URI (http://example.com/rdf-graphs/employees) is meant to identify RDF triples on the example.com server that describe employees. In addition, the request specifies the GET method, which means that a representation of these triples should be returned. In this case, the preferred representation format is application/rdf+xml

In this way, the server would route operations on a named graph in an Graph Store via its Graph IRI. However, in using a URI in this way, we are not directly identifying an RDF graph but rather the RDF graph content that is represented by an RDF document, which is a serialization of that graph. Intuitively, the set of interpetations that satisfy [RDF-MT] the RDF graph that the RDF document is a serialization of can be thought of as this RDF graph content.

The diagram illustrates this distinction. This diagram illustrates the basic kind of operation where the request URI identifies the RDF graph content being manipulated over the protocol.

Protocol model diagram
Figure 1: A diagram of the protocol model for direct graph references.

4.2 Indirect Graph Identification

Despite the convenience of using the request URI to identify RDF graph content for manipulation, it is often the case that:

As discussed in [RFC3986], query components are often used to carry identifying information in the form of key / value pairs where the value is another URI. This protocol leverages this convention and provides a specific interface whereby a graph IRI can be embedded within the query component of the request URI:

   GET /rdf-graphs/service?graph=http%3A//www.example.com/other/graph HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml

In the example above, the embedded graph IRI (http://www.example.com/other/graph) is percent-encoded [RFC3986] and indirectly identifies RDF triples to manipulate. Any server that implements this protocol and receives a request URI in this form SHOULD invoke the indicated operation on the RDF graph content identified by the IRI embedded in the query component where the IRI is the result of percent-decoding the value associated with the graph key. The embedded URI MUST be an absolute URI and the server MUST respond with a 400 Bad Request if it is not. The diagram below illustrates this.

Protocol model diagram for indirect manipulation
Figure 2: A diagram of the protocol model for indirect graph references.

In a similar manner, a query component comprised of the string default can be used to indicate that the operation indirectly identifies the default graph in the Graph Store. So, the example above can be modified to a request for an RDF/XML document that serializes the default graph in the Graph Store:

   GET /rdf-graphs/service?default HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml

In a request such as:

   GET /rdf-graphs/service?graph=http%3A//www.example.com/other/graph HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml

http://www.example.com/rdf-graphs/service identifies the HTTP service that implements this protocol. In order to dispatch requests to manage named or default graphs by embedding them in the query component of the service URL, the service URL will need to be known a priori. As will be discussed later in this document, both HTTP OPTIONS and GET requests can be sent to the service and the response to such a request is a service description document

As indicated in section 3.3 of [RFC3986], the path component (of a URI) contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component, serves to identify a resource within the scope of the URI's scheme and naming authority. So, the full request URI identifies the same RDF graph content as does the URI embedded in the query component that is managed by the authority.

5 Graph Management Operations

This section describes the use of the HTTP verbs to determine the operations performed on RDF graph content. In places where an equivalent SPARQL Update operation is given, <graph_uri> is understood to be either the request URI or the URI indirectly specified via the query component as described above. Similarly, in the case of an operation that manages the default graph, the SPARQL Update operation will not include any mention of a graph.

For operations involving an RDF payload (PUT and POST), the server MUST parse the RDF payload according to media type specified in the Content-Type header (if provided in the request). If this header is not provided, the server SHOULD attempt to parse the RDF payload as RDF/XML. Similarly, if the Accept header is not provided, the server SHOULD return an RDF XML document.

Developers of implementations of this protocol should refer to [RFC2616] for additional details of appropriate behavior beyond those specified here. Section 5 only serves to define the behavior specific to the manipulation af RDF graph content. For example, conditional requests that make use of headers such as If-Modified-Since that are intended to reduce unnecessary network usage should be handled appropriately by implementations of this protocol per [RFC2616].

5.1 Status Codes

In response to requests to the graph management operations specified in this protocol, implementations MUST include a status code [RFC2616] appropriate for the operation indicated and the result from invoking the operation. For example, in response to operations involving a RDF payload, if the attempt to parse the RDF payload according to the provided Content-Type fails then the server should respond with a 400 Bad Request.

A request using an unsupported HTTP verb in conjunction with a malformed or unsupported request syntax should recieve a response with a 405 Method Not Allowed. If the RDF graph content identified in the request does not exist in the server, and the operation requires that it does, a 404 Not Found response code SHOULD be provided in the response.


A request that uses the HTTP PUT method SHOULD store the enclosed RDF payload as RDF graph content. In the examples below, the initial HTTP request SHOULD be understood to have the same effect as the sequence of SPARQL Update operations that follow

    PUT /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...    
    DROP SILENT GRAPH <graph_uri>;
    INSERT DATA { GRAPH <graph_uri> { .. RDF payload .. } }   

In the case where the default graph is targeted (via default query component) for management, the following operations are equivalent

    PUT /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...    
    INSERT DATA { .. RDF payload .. } 

Either the request or the encoded URI (embedded in the query component) identifies the RDF payload enclosed with the request as RDF graph content. The server MUST NOT attempt to apply the request to some other resource. If the identified RDF graph content already exists, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the identified RDF graph content does not exist and that URI is capable of being defined as new RDF graph content by the requesting user agent, the origin server SHOULD create the RDF graph content with that URI in the underlying Graph Store. DROP is needed to remove any previous RDF graph content. Developers should refer to [SPARQL-UPDATE] for the specifics of how to handle empty graphs. In particular, if the request body is empty and there is sufficient authorization to create a new named graph with an IRI of that indicated by the request URI, then an empty graph would need to be created.

If new RDF graph content is created, the origin server MUST inform the user agent via the 201 Created response. If existing RDF graph content is modified, either the 200 OK or 204 No Content response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI (perhaps due to security considerations), an appropriate error response SHOULD be given that reflects the nature of the problem.


A request that uses the HTTP DELETE method SHOULD delete the RDF graph content identified by either the request or encoded URI. This method MAY be overridden by human intervention (or other means) on the origin server. If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code.

    DELETE /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com

Is equivalent to:

    DROP GRAPH <graph_uri> 

in the case where a named graph is targeted for management. Otherwise, the following

    DELETE /rdf-graphs/service?default HTTP/1.1
    Host: example.com

is equivalent to


A response code of 200 OK or 204 No Content SHOULD be given in the response if the operation succeeded or 202 (Accepted) if the action has not yet been enacted. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the RDF graph content or move it to an inaccessible location. In the event the operation is overridden, a response code of 403 Forbidden should be returned.


A request that uses the HTTP POST method SHOULD be understood as a request that the origin server perform an RDF merge of the enclosed RDF payload enclosed into the RDF graph content identified by the request or encoded URI. The following two operations are considered to have the same effect

    POST /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...    
    INSERT DATA { GRAPH <graph_uri> { .. RDF payload .. } }

In the case where a default graph is targeted for management, the following are equivalent

    POST /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...    
    INSERT DATA { .. RDF payload .. } 

If the request URI identifies the underlying Graph Store, the origin server SHOULD create a new RDF graph comprised of the statements in the RDF payload and return a designated graph IRI associated with the new graph. The new graph IRI should be specified in the Location HTTP header along with a 201 Created code and be different from the request URI. Within a service description document for an implementation of this protocol, the URI of an instance of the sd:Dataset class is understood to be the identifier of the Graph Store

So, given the following request and response:

    GET /rdf-graphs/service HTTP/1.1
    Host: example.com
    Accept: application/rdf+xml
    HTTP/1.1 200 OK
    Date: .. some date ..
    Server: ... etc ...
    Last-Modified: .. some date ..
    Etag: ".. etc .."
    Content-Length: .. length of service description document ..
    Connection: close
    Content-Type: text/turtle; charset=UTF-8
    @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
    @prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
    <> a sd:Service;
       sd:defaultDatasetDescription  <http://www.example.com/rdf-graphs> .
    <http://www.example.com/rdf-graphs> a sd:Dataset 

Then the following are equivalent:

    POST /rdf-graphs HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...    
    HTTP/1.1 201 Created
    Date: .. some date ..
    Server: ... etc ...
    Last-Modified: .. some date ..
    Location: http://example.com/rdf-graphs/newGraph1
    CREATE GRAPH <new_uri>
    INSERT DATA { GRAPH <new_uri> {.. RDF payload .. } } 

Where <new_uri> is a new URI that is designated by the service, is different from http://www.example.com/rdf-graphs, does not correspond to an existing graph IRI in the store, and is returned as the value of the Location HTTP header along with a 201 Created code.

This scenario is useful for situations where the requesting agent either does not want to specify the graph IRI of a new graph to create (via the PUT method) or does not have the appropriate authorization to do so. If the graph IRI does not identify either a Networked-manipulable Graph Store or RDF graph content, the origin server should respond with a 404 Not Found.

In either case, if the request body is empty, the implementation SHOULD respond with 204 No Content.

This protocol 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.


A request that uses the HTTP GET method SHOULD retrieve an RDF payload that is a serialization of the named graph paired with the graph IRI in the Graph Store.

The following two operations are considered to be equivalent

    GET /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    Accept: application/rdf+xml
    CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <graph_uri> { ?s ?p ?o } }

Where the request involves the default query component, the following two operations are equivalent

    GET /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    Accept: application/rdf+xml
    CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o } 

The response to such a SHOULD be made cacheable wherever possible and in any of the preferred representation formats specified in the Accept request-header field. In the event that the specified representation format is not supported, a 406 Not Acceptable response code should be returned.

5.5.1 Ambiguity Regarding the Range of HTTP GET (Informative)

Historically, there has been some ambiguity regarding the nature of what is returned from dereferencing a URI. When an HTTP GET is invoked with a request URI, what is returned and what is its relation to the resource identified by the request URI? In resolving this ambiguity, the W3C Technical Architecture Group specified a simple rule that determines the nature of the resource based on the response code returned. In this protocol, HTTP GET requests are used to retrieve a representation of the RDF graph content identified (directly or indirectly) by the Request-URI. Graph IRIs identify RDF graph content (an information resource) and so such a request should recieve a response with a 200 (Ok) which is consistent with these rules, the first of which states: If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource;

Information resources are resources with essential characteristics that can all be conveyed in a message [WEBARCH]. In this case, the characteristics of RDF graph content can be conveyed as RDF payload which serializes the named graph paired with the graph IRI in the underlying Graph Store. This protocol provides a means for requesting the representation without the need for indirection at the protocol level even if the naming authority associated with the URI of the named RDF graph in the Graph Store is not the same as the server managing the identified RDF graph content.


When used in this protocol, the HTTP HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. It is meant to be used for testing dereferencable URIs for validity, accessibility, and recent modification. The response to such a request from a server that manages a Graph Store MAY be cacheable. If the new field values indicate that the cached RDF graph content differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

5.7 HTTP PATCH (Informative)

The IETF specified Patch Method for HTTP can be used to request that a set of changes described in the request entity be applied to the named graph associated with the graph IRI of the RDF graph content resource identified by the Request-URI.

SPARQL 1.1 Update is RECOMMENDED for use as a patch document. In particular, SPARQL 1.1 Update requests that manage the graph associated with the RDF graph content identified (directly or indirectly) in the request can be used as the RDF payload of a HTTP PATCH request to modify it. If a SPARQL 1.1 Update request is used as the RDF payload for a PATCH request that makes changes to more than one graph or the graph it modifies is not the one indicated, it is RECOMMENDED that the server respond with a 422 Unprocessable Entity status. Such a request would be counter to the intuition that "REST uses a resource identifier to identify the particular resource involved in an interaction between components." [REST]

Intuitively, the difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the RDF graph content given by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the RDF graph content stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how the RDF graph content residing on the origin server should be modified to produce a new version.

5.8 Graph Store Service Discovery (Informative)

It is RECOMMENDED that the OPTIONS and GET methods be used in a request whose URI identifies the service that implements this protocol in order to retrieve information about the features of the service. Per section 2 of SPARQL 1.1 Service Descriptions, it is RECOMMENDED that a service description document be returned from such a request, especially if the implementation also supports the SPARQL Protocol for RDF.

This can aid a web agent in the client-side creation, and use of request URIs for the discovery and augmentation of an underlying Graph store by dispatching RDF documents to its content via HTTP operations.

6 Security Considerations

As with any protocol that is implemented as a layer above HTTP, implementations SHOULD take advantage of the many security-related facilities associated with it and are not required to carry out requested graph management operations that may be in contradistinction to a particular security policy in place. For example, when faced with an unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization is required. In cases where authentication is provided fails to meet the requirements of a particular access control policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the access control policy.

7 References

7.1 Normative References

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner, 1997. (See http://www.ietf.org/rfc/rfc2119.txt)
Uniform Resource Identifier (URI): Generic Syntax, Berners-Lee, Fielding, Masinter, January 2005.
Hypertext Transfer Protocol - HTTP/1.1. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.
Architecture of the World Wide Web, Volume One , N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/ . Latest version available at http://www.w3.org/TR/webarch/ .
Internationalized Resource Identifiers (IRIs), Duerst, Suignard, January 2005.
SPARQL 1.1 Update , S. Schenk, P. Gearon, Editor, W3C Working Draft, 26 January 2010, http://www.w3.org/TR/2010/WD-sparql11-update-20100126/ . Latest version available at http://www.w3.org/TR/sparql11-update/ .

7.2 Informative References

RDF Semantics , P. Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Latest version available at http://www.w3.org/TR/rdf-mt/ .
Representational State Transfer (REST) , R. Fielding, Ph.D. dissertation, 2000, Latest version available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm .
SPARQL Query Language for RDF , E. Prud'hommeaux, A. Seaborne, Editor, W3C Recommendation, 15 January 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ . Latest version available at http://www.w3.org/TR/rdf-sparql-query/ .

CVS History

$Log: Overview.html,v $
Revision 1.3  2018/10/09 13:24:46  denis
fix validation of xhtml documents

Revision 1.2  2017/10/02 10:44:03  denis
add fixup.js to old specs

Revision 1.1  2011/05/09 18:47:23  sandro
copied from 2009/sparql/docs/pub/20110512, and altered ../shared/local.css to shared.css

Revision 1.2  2011/05/06 08:48:02  apollere2
Fixed final TR location s/2010/2011/

Revision 1.1  2011/05/05 22:18:27  apollere2
Moved gen.html to Overview.html

Revision 1.4  2011/05/05 21:41:05  cogbuji
more of the same

Revision 1.3  2011/05/05 21:40:16  cogbuji
more XHTML WF checking

Revision 1.2  2011/05/05 21:29:43  cogbuji
XML wf commit

Revision 1.1  2011/05/05 21:26:46  cogbuji
initial commit for LC publication

Revision 1.76  2011/03/28 15:05:47  cogbuji
- Changed title to SPARQL 1.1 Graph Store HTTP Protocol
- Changed title of 5.8 to 'Service Description Requests (Informative)'
- Clarified behavior of empty PUTs with redirect to Update language specification
- Clarified behavior of empty POST
- Clarified that SD vocabulary should only be used if implementation is also a SPARQL protocol
for RDF implementation
- Removed use of 'extension' vocabulary to describe components of Graph Store protocol model.

Revision 1.75  2011/03/08 12:10:07  cogbuji
added description of SD RDF statements regarding dataset protocol and graph store

Revision 1.74  2011/02/19 22:43:24  cogbuji
IRI -> URI (per Jeremy's suggestion)

Revision 1.73  2011/02/18 04:43:01  cogbuji
addressed various comments in http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0274.html

Revision 1.72  2011/02/08 21:36:16  cogbuji
fixed HTTP headers in example

Revision 1.71  2011/02/08 21:32:02  cogbuji
minor rewording.  addressed inconsistencies in examples and their references to services v.s. graph stores.  added an example for the POST to graph store scenario. Updated the diagrams to reflect updated terminology

Revision 1.70  2011/02/05 04:43:27  cogbuji
various changes to address Andy S. review of prior to LC.  See: http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0182.html

Revision 1.69  2011/01/25 16:32:59  cogbuji
updated title to 'SPARQL 1.1 RDF Dataset HTTP Protocol' per 1/25/2011 WG resolution

Revision 1.68  2011/01/25 14:45:25  cogbuji
Changed 'RDF knowledge' to 'RDF graph content'.  Removed section on relative Base URI resolution (for relative values in the graph query component).  Added language requiring that query component values are absolute URIs.  Added language clarifying the role of the REST architectural style and the intention behind the specification

Revision 1.67  2010/12/21 03:04:22  cogbuji
removed working draft header

Revision 1.66  2010/12/20 22:09:24  cogbuji
removed reference to Network-manipulable Graph Store and changed SPARQL Update examples to account for default graph management semantics.

Revision 1.65  2010/12/20 19:06:47  cogbuji
- Added text clarifying what to do if the content-type header is not provided
- Added text clarifying the use of 204 and 404 in response to HTTP DELETE requests

Revision 1.64  2010/12/20 18:59:26  cogbuji
The following changes were committed to the editor's draft of the SPARQL 1.1 HTTP Protocol:

- Per Ian D.s comment, Serialize (verb.) was added to the terminology section to clarify the use of the word between RDF graphs and documents
- All references to Network-manipulable Graph Store were removed (the use of ?default removes the last vestige of a distinction from a Graph Store)
- Other minor typos
- Added description of ?default mechanism to 4.2
- Added text describing that (for indirect requests via embedded graph URIs), the part minus the query identifies the service which can be targetted
- Added text tying in RFC-3986's statements regarding the scope of what the path + query component identify to conclude that indirect, embedded
requests identify the same RDF knowledge as does the embedded URI itself (this is new and figure 2 has been updated to reflect this)
- The behavior of the use of HTTP PATCH with SPARQL Update documents is clarified along with appropriate status codes to respond with
- The non-normative language at the end of section 8 has been modified such that the response to OPTION/GET requests to the service directly
return service description documents

Revision 1.63  2010/10/08 02:57:11  cogbuji
minor touch up

Revision 1.62  2010/10/08 02:55:22  cogbuji
updated change summary

Revision 1.61  2010/10/08 02:46:11  cogbuji
updates for pubrules

Revision 1.60  2010/10/08 02:11:02  cogbuji
addressing well formedness issues for pubrules

Revision 1.59  2010/10/08 02:08:11  cogbuji
fixes for XML wfness

Revision 1.58  2010/10/08 02:06:16  cogbuji
updates to fix pubrules

Revision 1.57  2010/10/08 01:31:17  cogbuji
updates for publication

Revision 1.56  2010/09/15 00:27:11  cogbuji
changes to language regarding HTTP Patch to remove use of RFC 2119 language

Revision 1.55  2010/08/03 12:34:27  cogbuji
added HEAD, informative PATCH, and update to httpRange section regarding OPTION, and laxing language regarding 303

Revision 1.54  2010/08/02 20:42:10  cogbuji
fix to abstract

Revision 1.53  2010/08/02 20:36:02  cogbuji
last small fix

Revision 1.52  2010/08/02 20:34:08  cogbuji
grammar fix

Revision 1.51  2010/08/02 20:33:09  cogbuji
small fixes

Revision 1.50  2010/08/02 20:27:35  cogbuji
removed 'previous version' link

Revision 1.49  2010/08/02 20:26:40  cogbuji
Replaced the term Networked RDF knowledge with RDF knowledge, replaced the term Network-manipulable RDF dataset with Network-manipulable Graph Store, and reconcied definitions from the SPARQL Update document.  Added response code descriptions, added section describing relationship to httpRange-14 and various other changes

Revision 1.48  2010/05/25 18:17:51  lfeigenb
small pub fixes, added pub date

Revision 1.47  2010/05/20 20:44:51  cogbuji
yet another validation fix

Revision 1.46  2010/05/20 20:43:50  cogbuji
another XHTML validation fix

Revision 1.44  2010/05/20 20:40:04  cogbuji
various pubrules related fixes

Revision 1.43  2010/05/20 19:46:38  cogbuji
switch to WD template and added change summary in SOTD section in prep for publication

Revision 1.42  2010/05/18 13:26:48  cogbuji
Cleaned up language regarding alternative container POST behavior, broken SPARQL Update Language syntax, and added an editorial note about discovering the Network-manipulable Graph Store URI.  Updated diagram

Revision 1.41  2010/05/17 23:30:00  cogbuji
fixed double numbering of outline

Revision 1.40  2010/05/17 23:22:09  cogbuji
Updates in response to Greg's review:


Revision 1.39  2010/03/08 19:44:36  cogbuji
Removed two editorial notes, added (to section 5) a sentence addressing handling of Content-Type headers (so there should not be anymore ambiguity about handling different kinds of payloads)

Revision 1.38  2010/01/25 17:26:47  apollere2
changed status linki for IPP.

Revision 1.37  2010/01/25 16:55:45  apollere2
changed pointer to WG.

Revision 1.36  2010/01/25 16:48:19  apollere2
Changed URI to example.org.

Revision 1.35  2010/01/25 16:46:28  apollere2
changed link to WG.

Revision 1.34  2010/01/25 16:35:14  apollere2
fixed small validation error.

Revision 1.33  2010/01/25 16:34:25  apollere2
Added mentions of the group, requests for feedback, etc.

Revision 1.32  2010/01/25 15:31:14  bertails
~ fix based on Ian's suggestion (re: pubrules checker)

Revision 1.31  2010/01/24 15:16:23  apollere2
fixed broken anchor.

Revision 1.30  2010/01/24 15:12:39  apollere2
Fixed last validation error.

Revision 1.29  2010/01/23 03:17:20  cogbuji
- Final updates in preparation for publication (summary of updates, toc, etc..)

Revision 1.28  2010/01/22 02:17:46  apollere2
Added no-endorsement and patents boilerplate.

Revision 1.27  2010/01/22 02:12:04  apollere2
Made the date concrete.

Revision 1.26  2010/01/19 15:08:26  cogbuji
XHTML validation fixes

Revision 1.25  2010/01/19 15:00:57  cogbuji
Fix to make consistent use of language regarding URIs resolvable and otherwise that are request uris or embedded.  Updated diagrams, added a diagram for indirect reference via embedded URI

Revision 1.24  2010/01/12 15:10:11  cogbuji
references to percent-encoding and percent-decoding for new query component interface

Revision 1.23  2010/01/12 13:37:34  cogbuji
Added clause to also describe non-dereferencable URIs as motivation for the ?graph=.. interface

Revision 1.22  2010/01/12 07:04:08  cogbuji
From Lee's review
- editorial clarifications
- fixes to samples

Revision 1.21  2010/01/12 06:26:15  cogbuji
Incorporated changes suggested in review (http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0660.html) - mostly related to use of ?graph=uri, and fixes to SPARQL Update language snippets.

Revision 1.20  2009/12/14 20:16:51  cogbuji
updates to address comments from Leigh Dodds

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


Valid XHTML 1.0 Strict

Valid CSS!