HTTP Request Parameters

When Dydra processes a query request, it combines the algebra expression which it generates from the query text with several bits of metadata which it extracts from the protocol request or gathers from the request repository and system configuration.

Some of the properties are specified in the standards for the SPARQL language and request protocols. Others are specific to Dydra’s processing interface. Some are implicit in the standards, but no means is described to include them in a request. This document describes how to set these properties, either for individual queries or for all processing for a repostiory or an account, how these settings interact, and how a given effective setting affects the query processing.

The following properties govern query execution

parameter

request protocol

request text

repository configuration

account configuration

system configuration

access authentication key :

  • authentication-key. api-key (string)

URL, HEADER

base iri :

  • base-iri (iri)

URL

BASE

yes

user query id :

  • Client-Request-ID (string)

HEADER

dataset :

FROM, FROM-NAMED, WITH, WITH-NAMED

parameter

request protocol

request text

repository configuration

account configuration

system configuration

describe form:

URL

PREFIX

yes

yes

yes

dynamic binding :

  • $variable=value

URL

entailment mode :

  • entailment-ruleset, ruleset (iri list)

URL

PREFIX

yes

yes

yes

parameter

request protocol

request text

repository configuration

account configuration

system configuration

federation mode :

  • federation, federation-mode (urn):

    <urn:dydra:external>
    <urn:dydra:internal>
    <urn:dydra:none>

  • authorized-client-locations (iri, repository only)

  • authorized-service-locations (iri, repository only)

URL

PREFIX

yes

yes

yes

index:

  • property-index (list string iri)

yes

yes

yes

processing bounds:

  • memory-limit (integer)

  • solution-limit (integer)

  • time-limit, timeout (integer)

URL

PREFIX

yes

yes

yes

provenance mode :

  • provenance-repository-id (string)

URL

PREFIX

yes

yes

yes

parameter

request protocol

request text

repository configuration

account configuration

system configuration

repository id:

  • repository-id (string)

  • revision-uuid (string)

URL

response bounds :

  • limit, response-limit (integer)

  • offset, response-offset (integer)

URL

PREFIX

yes

yes

yes

response content type :

accept, response-content-type

HEADER

query text :

  • query (string)

URL DATA

revision id :

  • revision-uuid (string)

URL

revision-windows :

  • revision-window (string)

HEADER (MQTT)

parameter

request protocol

request text

repository configuration

account configuration

system configuration

skolemization mode :

  • skolemize (urn) :

<urn:dydra:skolemize>
<urn:dydra:skolemize-export>
<urn:dydra:skolemize-import>

  • skolemize-prefix (string)

URL

PREFIX

yes

yes

yes

undefined variable behavior :

  • undefined-variable-behavior (urn) :

URL

PREFIX

yes

yes

yes

user query id :

  • user-id (string)

  • user_id (string)

URL

xslt style sheet :

  • xslt (iri)

URL HEADER

values clauses :

  • values (string)

URL DATA

As these parameters may be specified in a number of ways, the Dydra query processor combines the values to produce the setting in effect for a given request. For those parameters which can be specified in the request, for example, the request dataset, the SPARQL protocol, requires that the protocol request values supercede any values present in the query text itself. Dydra applies the same rule to all parameters and, as an extension, supercedes any configuration values with those from the request. Among the configuration parameters, repository settings supercede those of the respective account, which supercede those of the system. In the case of a limit, however, no more specific value may increase the value beyond that of a more general setting.

When a request specifies a stored query, these precedence rules apply directly, as that stored query text is processed as if it were included in the request.

When, on the other hand, the processor caches queries, the cached instance entrains several of the original effective parameters in its compiled form. As a consequence, when the query is re-executed - whether by intent with new variable bindings or implicity, any compiled-in variations remain unaffected by any properties which change in the subsequent request. This is the case for the following parameters.

  • repository-id : a repository’s term and statement statistics affect pattern suppression and reordering as well as solution propagation.

  • dataset: iff a dataset was specified, the respective complement may be changed.

  • entailment mode : any applicable rules are compiled into the bgp interpretation.

  • federation mode : the mode determines sub-selects generated for implicit internal and explicit external cross-references.

  • base-iri: any initial base iri is used to expand qname terms when the query text is parsed.

  • undefined-variable-behavior: the mode determines the mechamism generated to interpret free variable references.

Where the request protocol indicates “MQTT”, the operation applies to streaming requests over MQTT only.

Revision Window Syntax

A request which intends to generate a repetitive result specifies the target revision’s temporal properties as a revision window. (See Revision Window Specification .)

Describe Form

A standard concise bounded description comprises the statments which share blank nodes as subject and object terms. In order to include statements which share other terms, specify <urn:dydra:true> as the `describeProperties`parameter.

The describeSubjectDepth refers to the depth to which a term serves to match statement subjects while the describeObjectDepth refers to the depth to which a term serves to match statement objects.

Query Text

The query text for a GET request is associated with the request query argument. This may appear as in the request URL as an argument or may be provided as an argument in a request form.

Values Clauses

The replacement text for values clauses is provided through arguments in a request form. This may appear as in the request URL as an argument or may be provided as an argument in a request form. The argument syntax corresponds to the datablock production of the SPARQL query syntax.

The correspondence between arguments and clauses in the query test is established on the basis of the clauses’ projection variables. See valuesClauses for an example.