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 repository end point in the form of a DELETE request

http://dydra.com/<account-name>/<source-repository-name>__<view-name>__<view-form>/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. This cache is augmented with indices for those variables in the view query which are prefixed with $ rather than ? . At least one must be present in order that the materialization process succeed.

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.

HEAD

A HEAD returns the repository description, as for a standard repository.

Headers

DELETE

A DELETE request regenerates the cached content. It executes the respective view query against the base repository and records the results in the materialzed cache. 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. (See GET .)

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-form>

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 $ .

form	index
view	a term number index is created for each parameter combination.
textview	a distinct text index is created for each parameter

Note that each index name combines the names of the source repository, the view, and the parameter. The name must be no longer than sixty-three characters.