SPARQL 1.1 Graph Store HTTP Protocol
The “SPARQL Graph Store Protocol”
as described in detail in the W3C
documentation,
comprises operations on Dydra repositories:
Upload content is limited to 128 MB. For synchronous requests, this applies to the compressed size, however for
asynchronous requests, this applies to the actual content.
Graph Store Requests
Standard graph store requests are addressed to the service graph store end point
http://dydra.com/<account-name>/<repository-name>/service
Any graph may be specified indirectly with a graph= or default query argument.
Alternatively, a graph HTTP header may apply.
A GET request may be targeted to a retrospective or prospective dataset by including a
revision-id or a revision-windows argument.
(See Revision Designator Specification and Revision Window Specification .)
HEAD
A HEAD request returns HTTP headers which comprise metadata about the repository.
DELETE
A DELETE request removes statements from the repository from the specified graph.
If no graph is specified, the operation applies to the entire repository content.
Headers
Accept: specifies the RDF response document media type.
Graph: specifies the statement context uri.
GET
A GET request returns the repository content.
If a revision is specified, the response contains those statements present as of that revision.
A request without a revision operates on the latest revision.
Headers
Accept: specifies the RDF response document media type.
Graph: specifies the statement context uri.
PUT
A PUT request clears the repository and inserts the request content.
Headers
Accept: specifies the RDF response document media type.
Client-Request-ID: specifies an id to be included in the response.
Content-Encoding: gzip, specifies content compression.
Content-Type: specifies the RDF content document media type.
Graph: specifies the statement context uri.
Location: specifies a content source alternative to the request body as an URL.
POST
A POST request appends the content to the repository.
Headers
Accept: specifies the RDF response document media type.
Client-Request-ID: specifies an id to be included in the response.
Content-Encoding: gzip, specifies content compression.
Content-Type: specifies the RDF content document media type.
Graph: specifies the statement context uri.
Location: specifies a content source alternative to the request body as an URL.
PATCH
A PATCH encodes changes to the repository as per the request content.
The modification mode depends on the content type.
Headers
Accept: specifies the RDF response document media type.
Client-Request-ID: specifies an id to be included in the response.
Content-Encoding: gzip, specifies content compression.
Content-Type: specifies the RDF content document media type.
The allowed media tpes are
- application/n-quads
- application/n-triples
- multipart/related
A multipart/related media type permits a boundary parameter.
Graph: specifies the statement context uri.
If the content media type is application/n-quads the request content denotes one
or more named graphs.
The request first removes the specified graph or graphs from the repository,
after which the request content n-quads statements are inserted into their respective graphs
and n-triples statements are inserted into the graph specified at the protocol level.
If the content media type is application/n-triples the request content denotes a single graph.
First, those statements which
are identified by the subjects which are present in the input are first deleted
and then, the content is inserted are inserted into the graph specified at the protocol level.
If the content media type is multipart/related, then each request part
modifies the repository as per the respective X-HTTP-Method-Override header by
inserting or removing those statements in the respective section.
TARQL Requests
TARQL defines an interpretation for SPARQL construct queries which allows
to apply them to CSV and JSON data to produce n-quads or n-triples data to import into a repository.
A TARQL request incorporates a SPARQL view in the graph store end point location.
http://dydra.com/<account-name>/<repository-name>/<tarql-view>
When a request to a location of this form appears in combination with text/csv
or application/json content,
the processor arranges to treat the content as the intermediate match results from
empty BGP forms and applies the algebra to the data to generate a graph, which is then imported.
Graph Store Response
The response to a graph store request indicates the disposition and provides provenance metadata.
If the import fails due to content syntax or due to overlapping update requests,
then the HTTP response code is “Bad Request”.
A successful operation will return “Created” or “Success” depending on whether the operation adds a new
graph or modifies an existing graph.
Headers
Content-Type: specifies the RDF response document media type.
ETag: specifies the revision identifier for the result repository state.
Location: specifies the repository resource identifier
Client-Request-ID : returns the client request id if one was present
Request-ID : returns the service request identifier.
Content
The content constitutes an activity stream entry and involves terms from two namespaces:
<http://www.w3.org/ns/activitystreams#> (as), and <http://www.w3.org/ns/prov#> (prov).
as:actor : the name of the task’s authenticated agent
as:id : the service request identifier
as:inReplyTo : the client request id if one was present
as:object : the repository resource identifier
prov:startedATime : the xsd:dateTime encoding of the ZULU time at which the request began
prov:endedATime : the xsd:dateTime encoding of the ZULU time at which the request completed