Syntax extensions: Tracker SPARQL Library Reference Manual

## Syntax extensions

Tracker offers some SPARQL syntax extensions. These predate the existence of SPARQL 1.1 and stay for legacy reasons. These extensions should be used sparingly, if at all.

The SPARQL specifications define the following syntax to use a specific separator for the GROUP_CONCAT operation:

    GROUP_CONCAT (?var, separator=;)

Tracker additionally accepts a simplified syntax:

    GROUP_CONCAT (?u, ';')

The BOUND function, as defined in the SPARQL specification, only accepts variables as its single argument. Tracker additionally allows this function to deal with expressions, mainly allowing the nesting of other functions, e.g. functional properties:

    SELECT BOUND (nfo:fileName (?u)) { ?u a nfo:FileDataObject }

Tracker accepts subselects in place of expressions, these subselects should return a single variable in order to act as a expression. E.g. this query:

    SELECT (SELECT ?ret { ?u nie:hasPart ?elem }) { ?elem a nfo:Folder }

Would be equivalent to this:

    SELECT nie:hasPart(?elem) { ?elem a nfo:Folder }

Tracker allows the use of SILENT after INSERT and DELETE keywords. Errors will be consequently silenced.

Tracker adds a special `INSERT OR REPLACE` operation. This form of update will overwrite any existing values.

    INSERT OR REPLACE { <file:///> nfo:fileName 'root' }

This operation works the same independently of the cardinality, multi-valued properties are cleared before the insertion.

If clearing a property is desired within the operation, the value list may also contain the NULL keyword, e.g.:

    INSERT OR REPLACE { <file:///> nie:hasPart <a>, <b>, NULL, <c> }

Note that the `DELETE { … } INSERT { … } WHERE { … }` syntax available in SPARQL 1.1 is a more versatile replacement.

Tracker allows the use of expressions in `ORDER BY` clauses, e.g.:

    SELECT { … } ORDER BY (?a - ?b)

The SPARQL 1.1 specifications enforce that all expressions returned in a `SELECT` clause are set a variable name, e.g.:

    SELECT ((?a - ?b) AS ?sub) { … }

Tracker relaxes this restriction, and does not enforce that expressions are surrounded by parentheses, e.g.:

    SELECT ?a + ?b ?a - ?b AS ?sub { … }

Note that this hinders query readability (e.g. the example above returns 2 values, an unnamed sum expression, and a named subtraction), so its use is not recommended.

Tracker makes the use of the `;` separator between update clauses optional. Its use is still recommended for readability.

Tracker supports `CONSTRAINT GRAPH` and `CONSTRAINT SERVICE` clauses in the query prologue. These clauses limit the access outside of the specified graphs and services.

    # Only triples in the tracker:Audio graph will be returned
    CONSTRAINT GRAPH tracker:Audio
    SELECT * { ?s ?p ?o }

If a graph is specified within the query, but not allowed by a `CONSTRAINT GRAPH` clause, it will be effectively interpreted as an empty graph.

If a service is accessed within the query, but not allowed by a `CONSTRAINT SERVICE` clause, it will be interpreted as an error, unless `SERVICE SILENT` syntax is used. In that case it will be interpreted as an empty graph.

The `CONSTRAINT` clauses cannot be contradicted, multiple `CONSTRAINT` clauses effectively intersect the set of allowed graphs/services with previous clauses.

    CONSTRAINT GRAPH tracker:Video, tracker:Audio
    CONSTRAINT GRAPH tracker:Video
    # Only tracker:Video graph can be accessed
    SELECT * { ?s ?p ?o }

    CONSTRAINT GRAPH tracker:Video
    CONSTRAINT GRAPH tracker:Video, tracker:Audio
    # Only tracker:Video graph can be accessed
    SELECT * { ?s ?p ?o }

Disjoint sets result in an empty set of accessible graphs and services.

    CONSTRAINT GRAPH tracker:Video
    CONSTRAINT GRAPH tracker:Audio
    # There are no accessible graphs, this query returns no results
    SELECT * { ?s ?p ?o }