![]() |
![]() |
![]() |
![]() |
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 }