Graph Store View Materialization HTTP Protocol

The “Graph View Materialization Protocol” extends the W3C “SPARQL Graph Store HTTP Protocol” to manage the state of materialized view repositories as a side-effect of graph store requests.

A materialized view repository differs from a standard repository in that its content represents the results from applying a view to a base repository. The content is generated subsequent to a DELETE request to the materialized view repository and retained until the next DELETE.

both SELECT and CONSTRUCt source views are permitted.

Materialization Requests

Materialization requests are adressed to the graph store materialized end point in the form of a DELETE request

http://dydra.com/<account-name>/<source-repository-name>__<view-name>__view/service

The consequence is that the cached view result state is cleared and replaced with that from applying the view to the source repository anew.

A successful update to the materialization cache is reported to a specified location in the form of the same graph store response as returned for an immediate update. The direct response is a ‘204.

DELETE

A DELETE request regenerates the cached content. The request is executed asynchronously, with the final status reported to the specified location.

Headers

Accept-Asynchronous: notify.
Asynchronous-Method: the asynchronous response method
Asynchronous-Location: the http request location for the asynchronous notification
Asynchronous-Content-Type: the asynchronous response content type
Authorization: the request and notification authentication information
Client-Request-ID: the client id to be relayed with the asynchronous response

GET

A GET request is not defined

PUT

A PUT request is not defined.

POST

A POST request is not defined.

PATCH

A PATCH request is not defined.

Materialized Repository Management

Creation

Each view is maintained as a distinct repository which corresponds to a view on a source repository. In order to create a view, create a repository with a name which follows the pattern

<source-repository-name>__<view-name>__view

The update process compares the source view with the attributes of an existing cache before it performs an update and recreates the cache if the source view has changed.

Index

When the view is first generated, an index is created for each combination of those query variables in the named view sparql text which begin with $ .