index.html 55.7 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>SPARQL 1.1 Graph Store HTTP Protocol</title>
    <style type="text/css">
      /*<![CDATA[*/
      pre.data	{ border: thin solid #88AA88;
      background-color: #E8F0E8;
      margin: 1em 4em 1em 0em ; }

      .wgNote	{ border: 0.2em solid red;
      padding: 0.5em ;
      margin: 1em 4em 1em 2em ; }

      /*]]>*/
    </style>
    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base" />
    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
  </head>

  <body>

    <div class="head">
      <p><a href="http://www.w3.org/">
      <img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>

      <h1 id="main">SPARQL 1.1 Graph Store HTTP Protocol</h1>
      <h2>W3C Working Draft 12 May 2011</h2>
      <!--h2>Editor's Draft</h2-->
      <dl>
	<dt>This version:</dt>
	<dd><a href="http://www.w3.org/TR/2011/WD-sparql11-http-rdf-update-20110512/">http://www.w3.org/TR/2011/WD-sparql11-http-rdf-update-20110512/</a></dd>
	<dt>Latest version:</dt>
	<dd><a href="http://www.w3.org/TR/sparql11-http-rdf-update/">http://www.w3.org/TR/sparql11-http-rdf-update/</a></dd>
    <dt>Previous version:</dt>
    <dd><a href="http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/">http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/</a></dd>
	<dt>Editor:</dt>
	<dd>Chimezie Ogbuji, <a href="mailto:chimezie@gmail.com">chimezie@gmail.com</a>, Invited Expert<br /></dd>
      </dl>

      <p class="copyright">
      <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &#169; 2009 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&#174;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>

    </div>

    <hr title="Separator for header" />
    <div>
      <h2 class="notoc"><a id="abstract" name="abstract">Abstract</a></h2>
      <p>This document describes the use of HTTP operations for the purpose of managing a collection of graphs in the REST architectural style.</p>
    </div>
    <div>
      <h2 id="status">Status of This Document</h2>

      <p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

      <p>This is a <a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsWD">Last Call Working Draft</a>.</p>
      <p>The end date of the Last Call review period is 29 July 2011.</p>

<p>Comments on this document should be sent to <a href="mailto:public-rdf-dawg-comments@w3.org">public-rdf-dawg-comments@w3.org</a>, a mailing list with a <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg-comments">public archive</a>. Questions and comments about SPARQL that are not related to this specification, including extensions and features, can be discussed on the mailing list <a href="mailto:public-sparql-dev@w3.org">public-sparql-dev@w3.org</a>, (<a href="http://lists.w3.org/Archives/Public/public-sparql-dev">public archive</a>).</p>

      <p>
This document was produced by the <a href="http://www.w3.org/2001/sw/DataAccess/">SPARQL Working Group</a>, which is part
of the <a href="http://www.w3.org/2001/sw/Activity">W3C Semantic Web Activity</a>.
</p>


      <h4 class="no-toc no-num" id="change-summary">Change Summary</h4>
      <p>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.</p>

      <h4 class="no-toc no-num" id="no-endorsement">No Endorsement</h4>

<p><em>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.</em></p>

<h4 class="no-toc no-num" id="patents">Patents</h4>

<p><em>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/35463/status">public list of any patent disclosures</a> 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 <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure"> section 6 of the W3C Patent Policy</a>.</em></p>

    </div>
    <hr />

    <div class="toc">

      <h2><a id="contents" name="contents">Table of Contents</a></h2>

<ol>
    <li><a href="#introduction">Introduction</a></li>
    <li><a href="#terminology">Terminology</a></li>
    <li><a href="#protocol-model">Protocol Model</a></li>
    <li><a href="#graph-identification">Graph Identification</a>
        <ul style="list-style-type: none">
            <li>4.1<a href="#direct-graph-identification">Direct Graph Identification</a></li>
            <li>4.2 <a href="#indirect-graph-identification">Indirect Graph Identification</a></li>
            <!--li>4.3 <a href="#base-resolution">Resolving Relative References</a></li-->
        </ul>
    </li>
    <li><a href="#graph-management">Graph Management Operations</a>
        <ul style="list-style-type: none">
            <li>5.1 <a href="#status-codes">Status Codes</a></li>
            <li>5.2 <a href="#http-put">HTTP PUT</a></li>
            <li>5.3 <a href="#http-delete">HTTP DELETE</a></li>
            <li>5.4 <a href="#http-post">HTTP POST</a></li>
            <li>5.5 <a href="#http-get">HTTP GET</a>
                <ul style="list-style-type: none">
                    <li>5.5.1<a href="#httpRange-14">Ambiguity Regarding the Range of HTTP GET (Informative)</a></li>
                </ul>
            </li>
            <li>5.6 <a href="#http-head">HTTP HEAD</a></li>
            <li>5.7 <a href="#http-patch">HTTP PATCH (Informative)</a></li>
            <li>5.8 <a href="#http-option">Graph Store Service Discovery (Informative)</a></li>
        </ul>
    </li>
    <li><a href="#security">Security Considerations</a></li>
    <!--li>8 <a href="#conformance">Conformance</a></li-->
    <li><a href="#sec-bibliography">References</a></li>
</ol>

    </div>

    <hr />

    <h2>1 <a id="introduction" name="introduction">Introduction</a></h2>

    <p>This document describes updating and fetching RDF graph content from a Graph Store over HTTP in the REST style <a href="#REST">[REST]</a>.  In doing so, it appeals to the
    following interface constraints that comprise the REST architectural style:</p>
    <ol>
      <li>identification of resources</li>
      <li>manipulation of resources through representations</li>
      <li>self-descriptive messages</li>
    </ol>
    <p>It emphasises the following distinct concepts: RDF graph management action, the RDF graph content <em>identified</em> 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 <a href="http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html">Self-Describing Semantic Web</a></p>
    <p>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.</p>

    <p>When this document uses the words <em>MUST</em>, <em>MUST NOT</em>, <em>SHOULD</em>, <em>SHOULD NOT</em>,
    <em>MAY</em> and <em>RECOMMENDED</em>, and the words appear as emphasized text, they must be interpreted as described in
    <a href="http://www.faqs.org/rfcs/rfc2119.html">RFC 2119</a> <a href="#rfc2119">[RFC2119]</a>.</p>

    <p>This document is closely related to the following specifications:</p>
    <ul>
        <li>The <a href="http://www.w3.org/TR/sparql11-query/">SPARQL 1.1 Query</a> specification,  which extends the
        <a href="http://www.w3.org/TR/rdf-sparql-query/">first SPARQL query language specification</a>.</li>
        <li>The <a href="http://www.w3.org/TR/sparql11-update/">SPARQL 1.1 Update</a> specification, which describes an update language for RDF graphs.</li>
        <li>The <a href="http://www.w3.org/TR/sparql11-protocol/">SPARQL 1.1 Protocol</a> specification, which extends the SPARQL Protocol specification.</li>
        <li>The <a href="http://www.w3.org/TR/rdf-sparql-XMLres/"> SPARQL Query Results XML Format</a> specification defines an XML document format for
        representing the results of SPARQL SELECT and ASK queries.</li>
        <li>The <a href="http://www.w3.org/TR/sparql11-service-description/">SPARQL 1.1 Service Descriptions, </a> a method for discovering and vocabulary for
        describing SPARQL services made available via the SPARQL Protocol.</li>
    </ul>

    <h2>2 <a id="terminology" name="introduction">Terminology</a></h2>

    <p>
    The following terminology is used in this document:
    </p>

    <ul>
        <!--li><em>Architectural style</em> - An architectural design perspective that limits a system in order to induce harmonous behavior</li-->
        <li><em>Representation State Transfer architectural style (REST) <a href="#REST">[REST]</a></em> - An architectural style for distributed hypermedia systems.</li>
        <li><em>URI</em> - A Uniform Resource Identifier as defined in <a href="#rfc3986">[RFC3986]</a>. </li>
        <li><em>IRI</em> - An Internationalized Resource Identifier as defined in <a href="#rfc3987">[RFC3987]</a>. Before an IRI found in a document is used by HTTP, the IRI is first converted to a URI. </li>
        <li><em>Resource</em> - A network-accessible data object or service identified by an IRI, as defined in <a href="#rfc2616">[RFC2616]</a>. See <a href="#WEBARCH">[WEBARCH]</a> for further discussion on Resources.</li>
        <li><em>Resolvable URI</em> - A URI whose resource potentially has one or more representations available via invoking HTTP <strong>GET</strong> on the URI as defined in <a href="#WEBARCH">[WEBARCH]</a>. </li>
        <!--li><em>Serialize (verb.)</em> - When used in a sentence where the subject is an RDF document and the object is an RDF graph, this is understood to mean that the result of parsing the document is the graph.</li-->
        <li><em>RDF document</em> - A serialization of an RDF Graph into a concrete syntax.</li>
        <li><em>Graph Store</em> - A mutable repository of RDF graphs managed by one or more services <a href="#SPARQL-UPDATE">[SPARQL-UPDATE]</a>.</li>
        <li><em>Graph IRI</em> - An IRI involved in this protocol, specified as a request URI or embedded as the query component of a request URI, and corresponds to the IRI of a graph in the underlying Graph Store.   </li>
        <li><em>RDF graph content</em> - An information resource identified by the graph IRI of a named graph and managed by a server that implements this protocol or
        identified by an indirect operation on the default graph. See <a href="#WEBARCH">[WEBARCH]</a> for further discussion on Resources.</li>
        <!--li><em>Semantic</em> (adj.) , semantics (n.). Concerned with the specification of meanings. Often contrasted with syntactic to emphasize the distinction between expressions and what they denote <a href="#RDF-MT">[RDF-MT]</a>.</li-->
        <li><em>RDF payload</em> - The representation <a href="#rfc2616">[RFC2616]</a> comprised of an RDF document that is sometimes included with the body of invokations of the operations defined here.</li>
    </ul>

    <p>Implementations of this protocol are HTTP/1.1 servers <a href="#rfc2616">[RFC2616]</a> 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.</p>

    <h2>3 <a id="protocol-model" name="prot-model">Protocol Model</a></h2>

    <p>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.)</p>

   <h2>4 <a id="graph-identification" name="graph-identification">Graph Identification</a></h2>

   <h3>4.1 <a id="direct-graph-identification" name="direct-graph-identification">Direct Graph Identification</a></h3>

   <p>We recall from <a href="#SPARQL">[SPARQL]</a> 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)</p>

   <p>Consider the following HTTP request to a server that implements this protocol:</p>

   <pre class="defn">
   GET /rdf-graphs/employees HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml
   </pre>

   <p>Per <a href="#rfc2616">[RFC2616]</a>, 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 (<strong>http://example.com/rdf-graphs/employees</strong>) is meant to identify RDF triples on the example.com server that describe
   employees.  In addition, the
   request specifies the <strong>GET</strong> method, which means that a representation of these triples should be returned.  In this case,
   the preferred representation format is <em>application/rdf+xml</em></p>

   <p>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 <em>directly</em> 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 <a href="#RDF-MT">[RDF-MT]</a> the RDF graph that the RDF document is a serialization of can be thought of as this RDF graph content.</p>

   <p>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.</p>

   <p><img src="ProtocolModel.jpg" alt="Protocol model diagram" /><br />
       <b>Figure 1</b>: A diagram of the protocol model for direct graph references.</p>

   <h3>4.2 <a id="indirect-graph-identification" name="indirect-graph-identification">Indirect Graph Identification</a></h3>

   <p>Despite the convenience of using the request URI to identify RDF graph content for manipulation, it is often the case that:</p>
   <ul>
     <li>the naming authority associated with the URI of an RDF graph in a Graph Store is not the same as the server managing the identified RDF content</li>
     <li>the naming authority is not available</li>
     <li>the URI is not <a href="http://www.w3.org/TR/webarch/#uri-dereference">dereferencable</a> (i.e., when dereferenced, it does not produce a RDF graph representation)</li>
   </ul>
   <p>As discussed in <a href="#rfc3986">[RFC3986]</a>, 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:</p>

   <pre class="defn">
   GET /rdf-graphs/service?<strong>graph</strong>=<em>http%3A//www.example.com/other/graph</em> HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml
   </pre>

   <p>In the example above, the embedded graph IRI (<code>http://www.example.com/other/graph</code>) is percent-encoded <a href="#rfc3986">[RFC3986]</a> and <em>indirectly</em>
   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 <em>graph</em> key.  The embedded URI MUST be an absolute URI and the server MUST
   respond with a <code>400 Bad Request</code> if it is not.  The diagram below illustrates this.</p>

   <p><img src="ProtocolModelIndirect.jpg" alt="Protocol model diagram for indirect manipulation" /><br />
       <b>Figure 2</b>: A diagram of the protocol model for indirect graph references.</p>

   <p>In a similar manner, a query component comprised of the string <em>default</em> 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:</p>

   <pre class="defn">
   GET /rdf-graphs/service?<strong>default</strong> HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml
   </pre>

   <p>In a request such as:</p>

   <pre class="defn">
   GET /rdf-graphs/service?<strong>graph</strong>=<em>http%3A//www.example.com/other/graph</em> HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml
   </pre>

   <p><code>http://www.example.com/rdf-graphs/service</code> 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 <strong>OPTIONS</strong> and <strong>GET</strong> requests can be sent to the service and the response
     to such a request is a service description document</p>
   <p> As indicated in <a href="http://www.apps.ietf.org/rfc/rfc3986.html#sec-3.3">section 3.3</a> of <a href="#rfc3986">[RFC3986]</a>, 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.</p>

   <h2>5 <a id="graph-management" name="graph-management">Graph Management Operations</a></h2>

   <p>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,
   &lt;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.</p>

   <p>For operations involving an RDF payload (PUT and POST), the server MUST parse the RDF payload according to media type specified in the <em>Content-Type</em> 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
   <em>Accept</em> header is not provided, the server SHOULD return an RDF XML document.</p>

   <p>Developers of implementations of this protocol  should refer to <a href="#rfc2616">[RFC2616]</a> 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 <a href="#rfc2616">[RFC2616]</a>.</p>

    <h3>5.1 <a id="status-codes" name="http-put">Status Codes</a></h3>

<p>In response to requests to the graph management operations specified in this protocol, implementations MUST include a status code <a href="#rfc2616">[RFC2616]</a> 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 <em>Content-Type</em> fails then the server should respond with a <code>400 Bad Request</code>.</p>

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

   <h3>5.2 <a id="http-put" name="http-put">HTTP PUT</a></h3>

   <p>A request that uses the HTTP <strong>PUT</strong> 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</p>

      <pre class="defn">
    PUT /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...
    </pre>

   <pre class="defn">
    DROP SILENT GRAPH &lt;graph_uri>;
    INSERT DATA { GRAPH &lt;graph_uri> { .. RDF payload .. } }
   </pre>

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

      <pre class="defn">
    PUT /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...
    </pre>


   <pre class="defn">
    DROP SILENT DEFAULT;
    INSERT DATA { .. RDF payload .. }
   </pre>

   <p>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.  <strong>DROP</strong> is needed to remove any previous
   RDF graph content.  Developers should refer to <a href="#SPARQL-UPDATE">[SPARQL-UPDATE]</a> 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.</p>

   <p>If new RDF graph content is created, the origin server MUST inform the user agent via the <code>201 Created</code> response. If existing RDF graph content
   is modified, either the <code>200 OK</code> or <code>204 No Content</code> 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.</p>

   <h3>5.3 <a id="http-delete" name="http-delete">HTTP DELETE</a></h3>

   <p>A request that uses the HTTP <strong>DELETE</strong> 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
    <code>404 Not Found</code> response code.</p>

    <pre class="defn">
    DELETE /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    </pre>

    <p>Is equivalent to:</p>
    <pre class="defn">
    DROP GRAPH &lt;graph_uri>
    </pre>

    <p>in the case where a named graph is targeted for management.  Otherwise, the following</p>

    <pre class="defn">
    DELETE /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    </pre>

    <p>is equivalent to</p>

    <pre class="defn">
    DROP DEFAULT
    </pre>

    <p> A response code of <code>200 OK</code> or <code>204 No Content</code> 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 <code>403 Forbidden</code>
   should be returned.</p>

   <h3>5.4 <a id="http-post" name="http-post">HTTP POST</a></h3>

   <p>A request that uses the HTTP <strong>POST</strong> 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</p>

    <pre class="defn">
    POST /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...
    </pre>

    <pre class="defn">
    INSERT DATA { GRAPH &lt;graph_uri> { .. RDF payload .. } }
    </pre>

    <p>In the case where a default graph is targeted for management, the following are equivalent</p>

    <pre class="defn">
    POST /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...
    </pre>

    <pre class="defn">
    INSERT DATA { .. RDF payload .. }
    </pre>

    <p>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 <code>201 Created</code> 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</p>

    <p>So, given the following request and response:</p>

    <pre class="defn">
    GET /rdf-graphs/service HTTP/1.1
    Host: example.com
    Accept: application/rdf+xml
    </pre>

    <pre class="defn">
    <a id="graph-store-description-example"/>
    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: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
    @prefix sd: &lt;http://www.w3.org/ns/sparql-service-description#> .

    &lt;> a sd:Service;
       sd:defaultDatasetDescription  &lt;http://www.example.com/rdf-graphs> .
    &lt;http://www.example.com/rdf-graphs> a sd:Dataset
    ..snip..
    </pre>

    <p>Then the following are equivalent:</p>

    <pre class="defn">
    POST /rdf-graphs HTTP/1.1
    Host: example.com
    Content-Type: application/rdf+xml
    ... RDF payload ...
    </pre>

    <pre class="defn">
    HTTP/1.1 201 Created
    Date: .. some date ..
    Server: ... etc ...
    Last-Modified: .. some date ..
    Location: http://example.com/rdf-graphs/newGraph1
    </pre>

    <pre class="defn">
    CREATE GRAPH &lt;new_uri>
    INSERT DATA { GRAPH &lt;new_uri> {.. RDF payload .. } }
    </pre>

    <p>Where &lt;new_uri> is a new URI that is designated by the service, is different from <em>http://www.example.com/rdf-graphs</em>, 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 <code>201 Created</code> code.</p>

    <p>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 <code>404 Not Found</code>.</p>

    <p>In either case, if the request body is empty, the implementation SHOULD respond with <code>204 No Content</code>.</p>

    <p>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
    <em>different</em> operations performed via the HTTP POST method.</p>

    <h3>5.5 <a id="http-get" name="http-get">HTTP GET</a></h3>

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

    <p>The following two operations are considered to be equivalent</p>

    <pre class="defn">
    GET /rdf-graphs/service?graph=..graph_uri.. HTTP/1.1
    Host: example.com
    Accept: application/rdf+xml
    </pre>

    <pre class="defn">
    CONSTRUCT { ?s ?p ?o } WHERE { GRAPH &lt;graph_uri> { ?s ?p ?o } }
    </pre>

    <p>Where the request involves the <em>default</em> query component, the following two operations are equivalent</p>

    <pre class="defn">
    GET /rdf-graphs/service?default HTTP/1.1
    Host: example.com
    Accept: application/rdf+xml
    </pre>

    <pre class="defn">
    CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }
    </pre>

    <p>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 <code>406 Not Acceptable</code> response code should be returned.</p>

    <h4>5.5.1 <a id="httpRange-14">Ambiguity Regarding the Range of HTTP GET (Informative)</a></h4>

    <p>Historically, there has been some <a href="http://www.w3.org/2001/tag/issues.html#httpRange-14">ambiguity</a> regarding the nature of what
        is returned from dereferencing a URI.  When an HTTP <strong>GET</strong> 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 <a href="http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039">simple rule</a>
        that determines the nature of the resource based on the response code returned.  In this protocol, HTTP <strong>GET</strong> 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 <code>200 (Ok)</code> which is consistent
        with these rules, the first of which states:

    <span>If an "http" resource responds to a <strong>GET</strong> request with a <code>2xx</code> response, then the resource identified by that URI is an information resource;</span>
    </p>
    <p>Information resources are resources with essential characteristics that can all be conveyed in a message <a href="#WEBARCH">[WEBARCH]</a>.  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.</p>

    <h3>5.6 <a id="http-head" name="http-get">HTTP HEAD</a></h3>

    <p>When used in this protocol, the HTTP <strong>HEAD</strong> method is identical to <strong>GET</strong> 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.</p>
    <h3>5.7 <a id="http-patch">HTTP PATCH</a> (Informative)</h3>
    <p>
        The IETF specified <a href="http://tools.ietf.org/html/rfc5789">Patch Method for HTTP</a> 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. </p>
    <p>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 <code>422 Unprocessable Entity</code> 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." <a href="#REST">[REST]</a></p>
    <p>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.
    </p>
    <!--h2>6 <a id="conditions" name="conditions">Conditional Requests</a></h2>
    <p>The semantics of an invocation of any of the operations in this protocol is conditioned on an additional set of criteria if the request message includes an
    If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field that indicate this criteria. Such an invocation SHOULD be used to
    request that the operation be performed only under the circumstances described by the conditional header field(s).  For example, a conditional <strong>GET</strong> requests
    that the graph representation be transferred only under the circumstances described by the conditional header field(s) (see <a href="#rfc2616">[RFC2616]</a> for more information on this)
    and 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.</p-->
    <h3>5.8 <a id="http-option">Graph Store Service Discovery (Informative)</a></h3>
    <p>It is RECOMMENDED that the <strong>OPTIONS</strong> and <strong>GET</strong> 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 <a href="http://www.w3.org/TR/sparql11-service-description/">SPARQL 1.1 Service Descriptions</a>, 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.</p>

    <p>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.</p>
    <!--p>Service description RDF statements can be made about the <a id="dataset-protocol-descriptions">Graph Store</a> being managed by an implementation of this
        protocol (as in the example <a href="#graph-store-description-example">above</a>).  These statements can aid a web agent in discovering and augmenting the
        underlying Graph store (<code>http://www.example.com/rdf-graphs</code>) by dispatching RDF documents to its content via HTTP POST operations. They also aid in the client-side creation
        and use of request URIs for subsequent HTTP operations on RDF graph content that must be indirectly identified in the request (for e.g: <code>http://www.example.com/rdf-graphs/service?graph=..</code>)
        as well as the default graph.</p>
    <p>In such a use of Service Description RDF graphs to
    describe the components of this protocol, the protocol listener itself (<code>http://www.example.com/rdf-graphs/service</code>) can be stated as being an instance of the <code>sd:Service</code> class
        wherein the graph store being managed is the corresponding default dataset.  Note, the graph store could more appropriately be stated as an instance of a <code>sd:RESTDataset</code> class
        , which is disjoint from <code>sd:Dataset</code> @@ Inconsistency @@.
    As required by the SPARQL 1.1 Service Description document, the protocol listener would also need to implement the SPARQL Protocol for RDF.</p-->

    <h2>6 <a id="security" name="security">Security Considerations</a></h2>
    <p>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
    <code>401 status code (Unauthorized)</code>, 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
    <code>403 status code (Forbidden)</code> can be sent back to the client to indicate this failure to meet the access control policy.</p>

    <!--h2>8 <a id="conformance" name="conformance">Conformance</a></h2>

    <p>@@Additional input is needed regarding whether specific language (beyond describing the expected behavior) is needed
    to determine levels of conformance</p-->

 <h2>7 <a id="sec-bibliography">References</a></h2>

<h3>7.1
<a id="section-Normative-References" name="section-Normative-References"></a>Normative References
</h3>

<dl class="bib">
<dt id="rfc2119">RFC2119</dt>
<dd>
  <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a>,
  Scott Bradner, 1997.  (See http://www.ietf.org/rfc/rfc2119.txt) </cite>
</dd>

<dt id="rfc3986">RFC3986</dt>
<dd><cite><a href="http://www.apps.ietf.org/rfc/rfc3986.html">Uniform Resource Identifier (URI): Generic Syntax</a></cite>, Berners-Lee, Fielding, Masinter, January 2005.
</dd>

<dt id="rfc2616">RFC2616</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol - HTTP/1.1</a></cite>. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,
June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.
</dd>


<dt>
<a name="WEBARCH" id="WEBARCH">WEBARCH</a>
</dt>
<dd>
<cite>
<a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture of the World Wide Web, Volume One</a>
</cite>, N. Walsh, I. Jacobs,  Editors, W3C Recommendation, 15 December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/ . <a href="http://www.w3.org/TR/webarch/">Latest version</a> available at http://www.w3.org/TR/webarch/ .</dd>

<dt id="rfc3987">RFC3987</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized Resource Identifiers (IRIs)</a></cite>, Duerst, Suignard, January 2005.</dd>

<dt>
            <a name="SPARQL-UPDATE" id="SPARQL-UPDATE">SPARQL-UPDATE</a>

         </dt>
         <dd>
            <cite>
               <a href="http://www.w3.org/TR/2010/WD-sparql11-update-20100126/">SPARQL 1.1 Update</a>
            </cite>, S. Schenk, P. Gearon, Editor, W3C Working Draft, 26 January 2010, http://www.w3.org/TR/2010/WD-sparql11-update-20100126/ . <a href="http://www.w3.org/TR/sparql11-update/" title="Latest version of SPARQL 1.1 Update">Latest version</a> available at http://www.w3.org/TR/sparql11-update/ .</dd>

</dl>

<h3>7.2
<a id="section-Infomrative-References" name="section-informative-references"></a>Informative References
</h3>

<dl>
<dt>
            <a name="RDF-MT" id="RDF-MT">RDF-MT</a>

         </dt>
         <dd>
            <cite>
               <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">RDF Semantics</a>
            </cite>, P. Hayes,  Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . <a href="http://www.w3.org/TR/rdf-mt/" title="Latest version of RDF Semantics">Latest version</a> available at http://www.w3.org/TR/rdf-mt/ .</dd>
<dt>
            <a name="REST" id="REST">REST</a>

         </dt>
         <dd>
            <cite>
               <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">Representational State Transfer (REST)</a>
            </cite>, R. Fielding, Ph.D. dissertation, 2000, <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" title="Latest version of RDF Semantics">Latest version</a> available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm .</dd>
<dt>
            <a name="SPARQL" id="SPARQL">SPARQL</a>

         </dt>
         <dd>
            <cite>
               <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/">SPARQL Query Language for RDF</a>
            </cite>, E. Prud'hommeaux, A. Seaborne, Editor, W3C Recommendation, 15 January 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ . <a href="http://www.w3.org/TR/rdf-sparql-query/" title="Latest version of Query Language for RDF">Latest version</a> available at http://www.w3.org/TR/rdf-sparql-query/ .</dd>
</dl>

<h3 id="cvs-history">CVS History</h3>

<pre>
 <!-- log starts on next line, not this one -->
$Log: Overview.html,v $
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:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0164.html

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

  </pre>

 <p>
    <a href="http://validator.w3.org/check?uri=referer"><img
        src="http://www.w3.org/Icons/valid-xhtml10-blue"
        alt="Valid XHTML 1.0 Strict" height="31" width="88" /></a>
  </p>
<p>
<a href="http://jigsaw.w3.org/css-validator/check/referer">
    <img style="border:0;width:88px;height:31px"
        src="http://jigsaw.w3.org/css-validator/images/vcss-blue"
        alt="Valid CSS!" />
</a>
</p>

  </body>

</html>