Feature:Assignment

From SPARQL Working Group
Revision as of 20:53, 6 August 2009 by Lfeigenb (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Feature: Assignment

In SPARQL/2008, only terms in the graphs used as variable bindings. This feature enables a simple, clear way to assign the value of an expression to a variable.

Feature description

This feature is described because of the interactions with other features (see below). It maybe that there is one mechanism with useful syntactic forms.

Example

Find people over 5'8" and return their names and heights.

SELECT ?name ?inch
{
   ?x foaf:name ?name 
   ?x :height ?cm .
   LET ( ?inch := ?cm/2.54 )
   FILTER (?inch > 68)
}

Existing Implementation(s)

Assignment in ARQ.

Assignment in Open Anzo (Glitter).

Existing Specification / Documentation

Assignment in ARQ.

Assignment in Open Anzo (Glitter).

Compatibility

This extension is only accessible through specific syntax and so can not change an existing legal query that does not use the syntax.

Links to postponed Issues

Related Features

This is strongly related to features project Expressions and nested queries, the latter in the case of a sub-select inside the graph pattern. Unlike assignment via sub-select and project expressions, explicit assignment happens in the flow of evaluation of a BGP; this can be more natural to write.

If expressions can be used in triple patterns instead of variables then LET can be avoided in many cases. Pattern OPTIONAL { X Y Z . LET (?opt := true) } FILTER (!bound(?opt))} can be written as UNSAID { X Y Z } .

LET lacks most of its expressivity without some sort of branching (IF or CASE ... WHEN as in SQL or COND in Lisp). At the same time LET can be compiled into SQL only if it can be macroexpanded to SPARQL that has no LETs. The implementation of the macroexpansion is trivial but its use is a bit limited.

Equivalence with SubSelects and ProjectExpressions

If we imagine the general form of "LET()":

(A)
LET(v1 = u1 .. vn = un)
(B)

where A and B are BGPs, then a plausible characterisation of this in relational algebra (N.B. SPARQL algebra has no explicit rename operation, but the SPARQL equivalent is easy to imagine) is:

v1/u1..vn/unπa1..an,u1..un(A))  (B)

where an are the names in A. given that, an equivalent projected expression would be

{ SELECT *, u1 AS v1 .. un AS vn WHERE { (A) } }
(B)

which also gives you

v1/u1..vn/unπa1..an,u1..un(A))  (B)

Champions

Use cases

  • From Holger Knublauch: We have many customers who rely on the ability to construct new RDF nodes (literals and URIs) as part of CONSTRUCT rules. Use cases include ontology mapping and deriving new values from existing ones.

References