Asynchronous Processing

Asynchronous processing concerns graph store requests which are not executed immediately to yield the completion code, but instead are queued for subsequent, serialized execution and notification through a separate request to an external location.

The request header Accept-Asynchronous governs this execution mode. If the value is not specified, the default is execute.

mode

effect

notify

The request is executed asynchronously returning a 204 status, the task identifier and any user id

execute

The request is executed immediately with the status and the result returned as response

Asynchronous Request Form

The asynchronous request is recorded in the form of an HTTP request object which captures the terms of the original request as several request headers and any context graph query argument. This includes the minimal authentication information and does not carry any client location information.

Asynchronous-Authorization

The authentication header for the notification request. If none is provided the authentication header from the original request is used.

Asynchronous-Content-Type

The content type for the notification request

Asynchronous-Location

The HTTP URL for the notification request

Asynchronous-Method

The HTTP method for the notification request

Authorization

The client authentication header to be used to execute the asynchronous import.

Client-Request-ID

The client request id to be reported with the notification request.

Content-Type

The content type to be used to execute the asynchronous import.

Context

The graph to be used to execute the asynchronous import. For a POST request, this will have been generated if none was provided

Request-ID

The task id from the initial request to be used to track the asynchronous execution.

Asynchronous Notification

The asynchronous notification take the form of an HTTP request to an external location as specified with the Asynchronous-* header values.

The method should be PUT or POST.

The content body describes the results from performing the actual import request. This takes the form a combined Activity Stream and Provenance Ontology entry in terms of

term

meaning

rdf:type

as:Update and the respective http method (htm:PATCH, htm:POST, htm:PUT)

as:id

The request UUID

prov:startedAtTime

The queued request start timestamp

prov:endedAtTime

The queued request end timestamp (if available)

as:actor

The request agent identifier

as:object

The abstract repository identifier

as:inReplyTo

Any client request identifier

for example

<urn:uuid:d2ce882e-2b98-4d42-b6db-48a47565c2f4> <http://www.w3.org/ns/activitystreams#id> <urn:uuid:d2ce882e-2b98-4d42-b6db-48a47565c2f4>  ;
    <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/activitystreams#Update>  ;
    <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2011/http-methods#PUT>  ;
    <http://www.w3.org/ns/prov#startedAtTime> "2018-03-30T22:02:11Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>  ;
    <http://www.w3.org/ns/prov#endedAtTime> "2018-03-30T22:02:11.640248Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>  ;
    <http://www.w3.org/ns/activitystreams#actor> <http://dydra.com/users/james>  ;
    <http://www.w3.org/ns/activitystreams#object> <http://dydra.com/openrdf-sesame/mem-rdf-write> .