SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs

1 Introduction

This specification applies the HTTP protocol semantics in managing and modifying RDF graphs. It emphasizes the distinction between an RDF graph management action, the networked body of RDF knowledge identified as the target of the action, the lexical form of a Request URI, the URI of a graph in an Network-manipulable Graph Store, and the (optional) RDF delivered with the message. This specification relies on an intuitive interpretation of the underlying HTTP protocol semantics to determine how the RDF graphs are modified. Where the meaning of the operations are described, an SPARQL Update equivalent syntax is shown for clarity.

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:

• The SPARQL 1.1/Query specification, which extends the first SPARQL query language specification.
• The SPARQL 1.1/Update specification, which describes an update language for RDF graphs.
• The SPARQL 1.1/Protocol specification, which extends the SPARQL Protocol specification.
• The SPARQL Query Results XML Format specification defines an XML document format for representing the results of SPARQL SELECT and ASK queries.
• The SPARQL 1.1/Service Descriptions, a method for discovering and vocabulary for describing SPARQL services made available via the SPARQL Protocol.

2 Terminology

The following terminology is used in this document:

• Representation State Transfer architectural style (REST) [REST] - An architectural style for distributed hypermedia systems.
• URI - A Uniform Resource Identifier as defined in [RFC3986].
• IRI - An Internationalized Resource Identifier as defined in [RFC3987]. Before an IRI found in a document is used by HTTP, the IRI is first converted to a URI.
• Resource - A network-accessible data object or service identified by an IRI, as defined in [RFC2616]. See [WEBARCH] for further discussion on Resources.
• Resolvable URI - A URI whose resource has one or more representations available via invoking HTTP GET on the URI as defined in [WEBARCH].
• RDF document - A serialization of an RDF Graph into a concrete syntax.
• Graph Store - A mutable repository of RDF graphs managed by a single service [SPARQL-UPDATE].
• Network-manipulable Graph Store - The subset of a Graph Store comprised of named RDF graphs that can be directly managed by interactions through this protocol
• Graph IRI - 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 Network-manipulable Graph Store.
• RDF knowledge - An information resource identified by the graph IRI of a named graph and managed by a server that implements this protocol. See [WEBARCH] for further discussion on Resources.
• Semantic (adj.) , semantics (n.). Concerned with the specification of meanings. Often contrasted with syntactic to emphasize the distinction between expressions and what they denote [RDF-MT].
• RDF payload - The representation [RFC2616] comprised of an RDF document that is sometimes included with the body of invokations of the operations defined here.

Implementations of this protocol are HTTP/1.1 servers [RFC2616] that interpet request messages as graph management operations on an underlying Network-manipulable 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 Network-manipulable Graph Store. In particular, it provides operations for removing, creating, and replacing RDF graphs as well as for adding RDF statements to existing RDF graphs . The HTTP operations defined here use URIs to route native HTTP operations to a Network-manipulable Graph Store. A compliant implementation of this specification SHOULD accept HTTP requests directed at its Network-manipulable 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 operation, which (intuitively) means that a representation of these triples should be returned. In this case the preferred representation format is application/rdf+xml

In this way, an HTTP request can route operations towards a named graph in an Network-manipulable 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 knowledge that is represented by an RDF document, which serializes that graph. Intuitively, the interpetations that satisfy [RDF-MT] the RDF graph serialized by the RDF document can be thought of as this RDF knowledge.

The diagram below attempts to emphasize this distinction. This diagram illustrates the most basic kind of operation where the request URI identifies the RDF knowledge being manipulated over the protocol.

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 knowledge for manipulation, it is often the case that the naming authority associated with the URI of an RDF graph in a Network-manipulable Graph Store is not the same as the server managing the identified RDF content, the naming authority is not available, or the URI is not dereferencable (i.e., when dereferenced, it does not produce a RDF graph representation). 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/employees?graph=http%3A//www.example.org/other/graph HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml
   

In the example above, the embedded graph IRI (http://www.example.org/other/graph) is percent-encoded [RFC3986], indirectly identifying 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 knowledge identified by the URI embedded in the query component where the URI is the result of percent-decoding the value associated with the graph key. The diagram below illustrates this.

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

4.3 Resolving Relative References

[RFC3986] defines the process of resolving a relative URI reference within a context. Implementations of this protocol SHOULD obey the rules specified there regarding the resolution of relative URI references. So, for example, the following HTTP request will result in a response with the RDF document that serializes the RDF graph whose graph IRI is http://example.com/rdf-graphs/employee/1:

   GET /rdf-graphs/service?graph=employee/1  HTTP/1.1
   Host: example.com
   

This is a result of the fact that the next applicable level of precedence designates the base URI to be the URI used to retrieve the representation (5.1.3 Base URI from the Retrieval URI) [RFC3986].

Similarly, the following HTTP request would trigger the update of the graph whose graph IRI is http://example2.com/rdf-graphs/employee/1:

    PUT /rdf-graphs/service/?graph=1  HTTP/1.1
    Host: example.com
    
    <?xml version='1.0' encoding='UTF-8'?>
      <rdf:RDF
        xml:base='http://example2.com/rdf-graphs/employees/' 
        xmlns:rdf='...'>
        ...
    </rdf:RDF>   
    

The xml:base attribute may be inserted in (RDF) XML documents to specify a base URI other than the base URI of the document or external entity. If the graph is identified indirectly (as in the above example), the request URI will identify a web resource other than the one indicated with the embedded URI. A PUT request, as described by this protocol, identifies the RDF payload enclosed with the request strictly as RDF knowledge and the xml:base attribute embedded in the payload (indicated in bold) provides an appropriate base URI to use for the operation

In situations where there is no Base URI in the payload and a graph IRI is embedded, the RDF document that represents [AWWW] the networked RDF knowledge identified by the embedded graph IRI SHOULD be considered the retrieval context (5.1.2) [RFC3986]. Thus, the default base URI is the base URI of that RDF document.

5 Graph Management Operations

This section describes the use of the HTTP verbs to determine the operations performed on RDF knowledge. 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. For operations involving a 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).

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 requests that use HTTP verbs not listed here or for which the syntax of the request is not defined in this protocol, the server SHOULD respond with 405 (Method Not Allowed) or 400 (Bad Request), respectively. 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 knowledge 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. Developers of implementations of this protocol should refer to [RFC2616] for additional details of appropriate behavior beyond those specified here. This section only serves to define the behavior specific to the manipulation af RDF knowledge.

5.1 HTTP PUT

A request that uses the HTTP PUT method SHOULD store the enclosed RDF payload as RDF knowledge . Any request that uses the method in this way SHOULD be be understood to have the same effect as the following sequence of SPARQL Update operations

    DROP SILENT GRAPH <graph_uri>;
    INSERT DATA { GRAPH <graph_uri> { .. RDF payload .. } }
   

Either the request or the encoded URI (embedded in the query component) identifies the RDF payload enclosed with the request as RDF knowledge. The server MUST NOT attempt to apply the request to some other resource. If the identified RDF knowledge already exists, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the identified knowledge does not exist and that URI is capable of being defined as new RDF knowledge by the requesting user agent, the origin server SHOULD create the knowledge with that URI in the underlying Network-manipulable Graph Store. Whether or not the DROP is neccessary in situations where the RDF knowledge does not already exist in the server depends on whether or not the Graph Store records the existence of empty graphs [SPARQL-UPDATE].

If new RDF knowledge is created, the origin server MUST inform the user agent via the 201 (Created) response. If existing RDF knowledge 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.

5.2 HTTP DELETE

A request that uses the HTTP DELETE method SHOULD delete the RDF knowledge identified by either the request or encoded URI. This method MAY be overridden by human intervention (or other means) on the origin server.

It is equivalent to:

DROP GRAPH <graph_uri> 

A response code of 200 (OK) 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 knowledge or move it to an inaccessible location. In the event the operation is overridden, a response code of 403 (Forbidden) should be returned.

5.3 HTTP POST

A request that uses the HTTP POST method SHOULD be understood as a request that the origin server incorporate the RDF payload enclosed in the request with the RDF knowledge identified by the request or encoded URI. A POST request is considered to have the same effect as the following SPARQL Update operation:

    INSERT DATA { GRAPH <graph_uri> { .. RDF payload .. } }
    

Alternatively, if the request URI identifies the underlying Network-manipulable 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.

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 knowledge, the origin server should respond with a 404 Not Found.

This document describes updating and fetching RDF data from a Network-manipulable Graph Store over HTTP in the REST style [REST]. It is a companion to the use of SPARQL/Update over the SPARQL protocol which uses HTTP POST to transmit a SPARQL/Update request. Both protocols specify different operations performed via the HTTP POST method.

5.4 HTTP GET

A request that uses the HTTP GET method SHOULD retrieve an RDF payload that serializes the named graph paired with the graph IRI in the Network-manipulable Graph Store.

This is equivalent to the following SPARQL query:

CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <graph_uri> { ?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.4 HTTP HEAD

The HTTP HEAD method SHOULD be used for obtaining metainformation about the RDF knowledge without transferring RDF payload. As described, it is meant to be used for testing dereferencable URIs for validity, accessibility, and recent modification.

The response to a HEAD request from a server that manages a Network-manipulable Graph Store MAY be cacheable. If the new field values indicate that the cached RDF knowledge 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.5 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 (for example, a SPARQL 1.1 Update request as a patch document) be applied to the named graph associated with the graph IRI of the RDF knowledge resource identified by the Request-URI.

Intuitively, the difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the RDF knowledge given by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the RDF knowledge 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 knowledge residing on the origin server should be modified to produce a new version.

6 Conditional Requests

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 GET requests that the graph representation be transferred only under the circumstances described by the conditional header field(s) (see [RFC2616] for more information on this) 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.

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

8 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 knowledge identified (directly or indirectly) by the Request-URI. Graph IRIs identify RDF knowledge (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 knowledge can be conveyed as RDF payload which serializes the named graph paired with the graph IRI in the underlying Network-manipulable 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 Network-manipulable Graph Store is not the same as the server managing the identified RDF knowledge.

It is RECOMMENDED that the OPTIONS method be used as a request for information about the communication options available. it enables the client to determine the options and/or requirements associated with some RDF knowledge, or the capabilities of a server, without implying an action or initiating a the retrieval of RDF payload. It is RECOMMENDED that the web address of SPARQL 1.1/Service Descriptions be provided in the response.

9 References

9.1 Normative References

RFC2119

RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner, 1997. (See http://www.ietf.org/rfc/rfc2119.txt)

RFC3986

Uniform Resource Identifier (URI): Generic Syntax, Berners-Lee, Fielding, Masinter, January 2005.

RFC2616

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.

WEBARCH

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

RFC3987

Internationalized Resource Identifiers (IRIs), Duerst, Suignard, January 2005.

RDF-MT

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

9.2 Informative References

REST

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-UPDATE

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

CVS History

 
$Log: Overview.html,v $
Revision 1.4  2018/10/09 13:23:06  denis
fix validation of xhtml documents

Revision 1.3  2017/10/02 10:42:15  denis
add fixup.js to old specs

Revision 1.2  2010/10/14 00:29:11  bertails
~ http://lists.w3.org/Archives/Team/webreq/2010Oct/0064.html

Revision 1.1  2010/10/08 06:02:45  apollere2
Adding Overview plus pictures.

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