Should <<>> syntax be added to expressions?

[afs]

This issue follows from the discussion about <<>> in expressions now that #6 is resolved with no operation for the special meaning for BIND. It splits discussion form issue #109 for this point item.

See
Telecon 2021-02-26
look for <pchampin> BIND(<<:bob a :Person>> AS ?t)

Case 1: Special form: BIND(<<:s :p :o>> AS ?t) to assign an embedded triple to a variable.

The elements of the << >> must be concrete terms. c.f. VALUES.

The change is in the grammar rule BIND. This does not allow << >> in a general expression.

Case 2: Allow variables: BIND(<<?s :p :o>> AS ?t)

Allow variables which must be bound at the point of evaluation (usual expression rules)

The change is in the grammar rule BIND. This does not allow << >> in a general expression.

Case 3: Add << >> to grammar at PrimaryExpression as << VarOrTerm VarOrTerm VarOrTerm >>.

This allow cases 1 and 2 and allows use in expressions.

Example 1: Use in COALESCE (a pattern for default values)

BIND(COALESCE(?var, <<?s :p :o>>) AS ?t1)

Example 2: Use in IF:

BIND(IF(isTriple(?var), ?var, <<?s :p :o>>) AS ?t2)

Example 3: Use with SUBJECT

BIND(SUBJECT(<<?s :p :o>>) AS ?t3)

Triple(s, p, o) allows an expression as argument; << >> does not.
<<?s ?p ?o>> is the same as Triple(?s, ?p, ?o)

Case 4: Add << >> to grammar and allows expressions.

This is not possible because expressions are separated by "," or ended with ")" (e.g. SELECT-AS). so simply adding << expression expression expression>> to UnaryExpression or anywhere else does not work. Other syntax would be needed e.g. VarOrTerm | BrackettedExpression.

[hartig]

From a syntax perspective, Case 2 is exactly what is currently captured by the grammar that we have for the SPARQL-star version of BIND (a.k.a. FIND) and that we will remove as per PR #115. Hence, if we decide to go with case 2 here, then we can bring the corresponding grammar production back in (but then with a different semantics of course).

[hartig]

Cases 1 and 2 seem to be the least disruptive options from an implementation perspective. In fact, these two can actually be introduced as shorthand for the TRIPLE function (#109). Then, when making a choice between these two cases, I would go for Case 2 because it is more expressive. The condition that the variables which must be bound at the point of evaluation is not a problem in my opinion because the same condition exists also for any other use of BIND.

[ericprud]

If case 2 allows for

BIND(<<?s :p :o>> AS ?t)
BIND(COALESCE(?var, <<?s :p :o>>) AS ?t)

, I expected users would assume those could be flattened into

BIND(COALESCE(?var, <<?s :p :o>>) AS ?t)

@afs , does 3 represent more work or just a different injection into the grammar?

[hartig]

If case 2 allows for

BIND(<<?s :p :o>> AS ?t) BIND(COALESCE(?var, <<?s :p :o>>) AS ?t)

This should not be possible. According to Section 10.1 of the SPARQL spec, "the variable introduced by the BIND clause must not have been used in the group graph pattern up to the point of use in BIND." Your second BIND clause here violates this condition.

[pchampin]

I can think of another case:

Case 2b: Add EmbTD (as proposed for the VALUES clause) to grammar at PrimaryExpression.

Variables between `<< ... >>`` would be allowed only in BGPs, but any Turtle-star term could still be used inside expressions, which I consider to be highly desirable.

Building embedded triples from variables would always require the function TRIPLE (just like building literals from variable always require functions such as STRDT and STRLANG).

[afs]

@olaf - They are separate examples, not one example. Reformatted to make that clear.

cc @ericprud

[afs]

Case 2b: Add EmbTD (as proposed for the VALUES clause) to grammar at PrimaryExpression.

We could. (This is case 3 with only constant embedded triples.)

Case 1 and 2 would be a special case of BIND.

For me, if we are allowing constants anywhere it seems strange not to allow EmbTP (with variables) because "it just works".

[afs]

For completeness:

Case 0: Do nothing. No <<>> syntax in expressions. Use TRIPLE.

(It is similar to the fact there are no constant blank nodes in expressions.)

[afs]

My current preference is case 3 (add EmbTP to PrimaryExpression) if we decide to have <<>> syntax.

[gatemezing]

I agree also to be able to have <<>> in the syntax.

[pchampin]

@afs since this is now included in the editor's draft, I propose to close this issue