Extend Graph Store HTTP Protocol to support operations on the RDF Dataset

[jaw111]

Why?

SPARQL 1.1 Graph Store HTTP Protocol only provisions for operations on a single graph per request (be it the default graph or a named graph). In many situations it is useful to operate on the complete or partial RDF Dataset as a resource.

Previous work

Dydra implements support for quads in graph store protocol: https://github.com/dydra/http-api-tests/blob/master/README.md#triples-quads-and-named-graphs-in-graph-store-import-and-update-requests

Proposed solution

• GET request would return complete RDF Dataset in a quads serialization (TriG / N-Quads / JSON-LD / ...)
• PUT request would overwrite complete RDF Dataset with RDF quads payload
• POST request would add the RDF quads payload to the existing RDF Dataset
• DELETE request would remove the complete RDF Dataset (equivalent to DROP ALL)
• PATCH request would overwrite the contents only of the graphs (default/named) in the RDF quads payload
  • Note that N-Quads does not provision for 'empty' graphs, so need to consider here if this should always treat the payload as quads, or allow for 'empty' graphs in formats like TriG and JSON-LD such that this would serve to clear those graphs in the RDF Dataset

Considerations for backward compatibility

None, this extends the existing SPARQL 1.1 Graph Store HTTP Protocol, but remains backwards compatible.

[afs]

+1 : Apache Jena Fuseki provides GET, POST, PUT, OPTIONS for quad formats - and triple go to the default graph.

I don't think it necessarily requires any change to Graph Store Protocol - it is more like documentation to describe how the HTTP verbs on a web resource apply when that resource is a dataset.

[namedgraph]

I've tried defining some high-level semantics for this (the Quad Store section): https://gist.github.com/namedgraph/64ef07b0a3a66092cfdcbf65eefbf00f#quad-store-functions Linked Data and Graph Store semantics are also provided.