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 for import

    • replacement (PUT)

    • addition (POST)

    • modification (PATCH)

  • clearing (DELETE)

  • download for export (GET)

Graph Store Requests

Standard graph store requests are adressed 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 targerted to a retrospective or prospective dataset by including a revision-id or a revision-windows argument. (See Revision Designator Specification and Revision Window Specification .)

DELETE

A DELETE request removes statements from the repository from the secified 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 cmpression.
Content-Type: specifies the RDF content document media type.
Graph: specifies the statement context uri.

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 cmpression.
Content-Type: specifies the RDF content document media type.
Graph: specifies the statement context uri.

PATCH

A PATCH encodes changes to the repository as per the request content.

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.

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 cmpression.
Content-Type: specifies the RDF content document media type. A multipart/related media type permits a boundary parameter. (see the PATCH-multipart test.)
Graph: specifies the statement context uri.

Part Headers

Content-Type: specifies the RDF part document media type.
Graph: specifies the part statement context uri.
X-HTTP-Method-Override: specifies the operation (PUT, POST, PATCH, or DELETE) to apply to the part content.

If the content media type is application/n-quads or application/n-triples the request content denotes a graph. 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.

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 identifer 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 activty 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