# Joseki: Query Languages

Joseki supports the dynamic loading of query language processors when the server starts. These query modules can be provided externally by the application or by some other party. The functionally provided with the Joseki distribution is just such modules dynamically loaded according to teh standard Joseki definitions file.

This page gives the HTTP binding of the query languages. All queries return a matching subgraph by default. See also: the Joseki RDF WebAPI description.

The Joseki distribution supports HTTP GET and provides the following query languages:

- RDQL
- Fetch
- SPO

There are classes in the Java and Python client-libraries to make queries in these various query languages without needing to understand the HTTP encoding of them.

## HTTP GET

A plain HTTP GET (no query string) is handled internally as a query request for the whole model.

## RDQL

See also: The Jena RDQL Tutorial

Parameter Name | Parameter Type/Value | Description
--- | --- | ---
lang (required) | Id. of query language | URI: http://jena.hpl.hp.com/2003/07/query/RDQL Short forms: "RDQL", "rdql"
query (required) | The query, as %encoded string | The RDQL query to be executed. As with all parameter values, this must be %-encoded.
format (optional) | "BV" | Other RDF graphs for the output formats for the result graph. The only additional format currently supported is a description of the bound variables, according to result set vocabulary.
closure (optional) | "true" or "false" | For each binding of a variable mentioned in the SELECT clause, which is bound to a bNode, the graph is augmented with the bNode closure from this point.

The bNode closure from a bNode is formed by adding all the statement with that node as subject, then recursing over any additional bNodes added as objects of those statements. Recursion stops where literals or labelled nodes are encountered. Cycles are detected and handled by avoiding infinite loops.

Only one of "format" paramter may be given

## Fetch

The fetch query language implements the idea of RDF data objects. A query consists of single "r" parameter, whose value is the URIref of the data object. The exact extent of the RDF returned is dependent on the server. Joseki provides a module that provides all statements with the resource as subject, then calculates the bNode closure of all objects of these statements. This is used in the book database examples.

Parameter Name | Parameter Value | Description
--- | --- | ---
lang (required) | Id. of query language | URI: http://jena.hpl.hp.com/2003/07/query/fetch Short forms: "fetch"
r (required) | URIref | URIref of the resource

## SPO

URI: http://jena.hpl.hp.com/2003/07/query/SPO

SPO (also known as "Triples") is an experimental minimal query language. An SPO query is a single triple pattern, with optional subject (parameter "s"), predicate (parameter "p"), and object (parameter "o", if a URIref, parameter "v" for a string literal). Absence of a parameter implies "any" for matching that slot of the triple pattern.

Such a query language is not suitable for all situations but is convenient some record oriented vocabularies, for example, simple Dublin Core.

Parameter Name | Parameter Value | Description
--- | --- | ---
lang (required) | Id. of query language | URI: http://jena.hpl.hp.com/2003/07/query/SPO Short forms: "SPO", "spo"
s (optional) | URIref | URIref of the subject of the triple pattern. Absence implies a wildcard match.
p (optional) | URIref | URIref of the subject of the triple pattern. Absence implies a wildcard match.
o (optional) | URIref | URIref of the subject of the triple pattern. Only one of "o" and "v" may be given
v (optional) | String | Literal value as a string. Absence or "o" and"v" implies a wildcard match.
closure (optional) | "true" or "false" | Calculate the bNode closure of the matched subgraph.