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