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 }