A very brief guide to the SPARQL Graph Store Protocol.

This email is some notes for the telecon slot on the SPARQL Graph Store 
Protocol (GSP).

 Andy

The document is:
http://www.w3.org/TR/sparql11-http-rdf-update/

"SPARQL 1.1 Graph Store HTTP Protocol"
   Editor: Chimezie Ogbuji

Motivation
   + Utility of simple actions to manage data
   => Easy to script and write data management tools
   => No need to have a complex subsystem.

or ... basic data management by "curl".

== Graph Store

A "graph store" is a collections of graphs - one unnamed, default graph 
and zero or more named slots.   Really, it is a collection of slots and 
it is the mutable version of an "RDF dataset".  SPARQL Update works on 
"graph stores", SPARQL Query works on "RDF datasets", which may be the 
the state of a graph store at the point of query execution.

SPARQL Update allows fine change and control of the a graph store.  But 
it is also convenient to work by using HTTP actions (GET, PUT, DELETE, 
POST) on whole graphs.  This is especially true if the default graph is 
the union of the named graphs, which is a common setup.  Then different 
parts of the default graph can be added and removed using GET, PUT, 
DELETE, POST, and by scripting common tools.

== HTTP Usage

The document describes using HTTP for graphs - it is not defining the 
HTTP verbs, rather it is explaining how HTTP is applied.

GET returns a graph
PUT replaces or creates a graph
DELETE removes a graph

The body of the actions is a serialized RDF graph with the usual content 
negotiation.

The only action defined is POST.  In HTTP (RFC 2616, sec 9.5) POST is 
not exactly defined but one usage is "Extending a database through an 
append operation."

For RDF data, it has been found useful to have POST to a graph mean to 
add triples to graph (or create it if it does not exist) as the "extend" 
action.  As an RDF graph has no ordering of the triples, adding triples 
this means add to the set.

The GSP doc also defines some things for graph stores:

POST to a graph store creates a new graph, a little like Basic Profile 
Containers.  It's simpler in SPARQL because the only thing you can post 
to a graph store is a graph (no containers inside containers) and there 
is no metadata.

GET on a graph store is not defined.  No quads formats is officially 
defined yet (but "coming soon" from RDF-WG) and some systems overload 
the URI of the graph store with the services for query and or update 
where GET is the service description.

There is informative text about PATCH but PATCH deployment isn't 
widespread.  The suggestion is the PATCH body is a SPARQL Update request.

== Graph Identification

The other part of the document is to do with identifying the unit to be 
acted upon when it is a graph.

"Direct Graph Identification" explains that using a URL is directly 
identifying the resource to act on in the normal HTTP/AWWW way.  While 
the graph is in some way in a graph store, there is nothing special 
here.  It looks just like a graph on the web.

    http://host/graph-store/
has a named graph
    http://host/graph-store/graph1

"Indirect Graph Identification" deals with the case of a named graph in 
a graph store where the named graph does not share the name of the graph 
store - it came from somewhere else, maybe the naming indicates original 
location.

    http://host/graph-store/
has a named graph
    http://example/abc/def

In this case the naming is done with the URI query string.

The default graph is  ?default
A named graph is  ?graph=http://example/foo (but %-encoded as well).

http://host/graph-store?graph=http%3A//example/foo

Received on Monday, 25 June 2012 11:25:36 UTC