Update data-r2 to be SPARQL 1.1 compatible

[afs]

This PR changes data-r2/ in place, no directory rename applied, for discussion of the changes needed.
This is why it is marked "draft".

This PR does not include PR #82 which is needed as well for the SPARQL 1.0 test suite to run.

Changes and reason:

dawg-optional-filter-005-simplified (expr-5.rq)

Only one of expr-5-result-simplified.ttl and expr-5-result-not-simplified.ttl can be right.

There was an mmbiguity in the SPARQL 1.0 spec.

expr-5-result-not-simplified.ttl is the preferred answer (simplify after all algebra generated, not as generated).

Also reformatted optional-filter/manifest.ttl

datatype-2 : Literals with a datatype (q-datatype-2.rq)

@lang has a datatype in RDF 1.1
Update: expr-builtin/result-datatype-2.srx

Strings: Distinct (distinct-1.rq)

RDF 1.1 "" is now the same as ""^^xsd:string
Updated distinct-str.srx

All: Distinct (distinct-1.rq)

Same.
"" is now ""^^xsd:string
Update distinct-all.srx

syntax-lit-08.rq (syntax-lit-08.rq)

Decimal form change.
Updated: syntax-sparql1/syntax-lit-08.rq

[gkellogg]

I think a change to PNAME_LN may affect syntax-esc-04 and syntax-esc-05, as well.

[afs]

Reader: syntax-esc-05 is

PREFIX : <http://example/> 
SELECT *
# Comments can contain \ u
# <\u0078> :\u0070 ?xx\u0078
WHERE { <\u0078> :\u0070 ?xx\u0078 }

I'm not seeing an error with SPARQL 1.1 on those tests. They do, however, trigger errors with the community position on \ u to be processed after parsing, in strings and IRIs, and nowhere else. That's the Turtle rules.

#67
w3c/sparql-dev#77

and @gkellogg comment #67 (comment)

Both the prefixed name and the variable lead to bad syntax by the community processing rule.

For the SPARQL rdf-tests, I think we should have a conservative "latest agreed" test suite.

I've created #84 for a general discussion and a reorganisation of the SPARQL tests to help implementers find the current tests. The new RDF-Star WG makes it a good time for that because it is also chartered for errata.

[afs]

Added a commit that makes syntax-esc-04 and syntax-esc-05 work for SPARQL 1.0, SPARQL 1.1 and the community consensus.

[gkellogg]

These all look good to me (but, eventually I need to better understand variable visibility as indicated by dawg-optional-filter-005-simplified (expr-5.rq), as I get the results in expr-5-result-simplified.ttl).

[afs]

Happy to discuss that test case ... where's good?

The difference is when simplification is applied. It matters for OPTIONAL because OPTIONAL { ... FILTER(...) } puts the filter into the LeftJoin expressions. In LeftJoin, the FILTER can see the left-hand-side variables. (SQL: LEFT JOIN ... ON ...)

For OPTIONAL { { ... FILTER(...) } }, the inner part is Join({}, {.... FILTER }).

if simplify happens while coming back up the tree generating algebra operations, it removes the join i.e. the inner of {{ }}, and passes "... FILTER()" to the OPTIONAL. The effect of the extra nesting in {{ }} is lost and it exposes the filter to the OPTIONAL rule.

if simplification happens as a step after the whole algebra is converted, this does not happen. Compiling the OPTIONAL see a join and the filter is not at the top level of the OPTIONAl block and so not handled in the LeftJoin.

Use case:

# Include name if person over 18
SELECT *
{ ?person :age ?age 
   OPTIONAL { ?person :name ?name. FILTER(?age > 18) }
}

Hindsight: a better syntax would be call out if the filter needed access to the LHS.

OPTIONAL FILTER(....) { }

But we are where we are.

(a "no conditions on LeftJoin" approach would mean users having to duplicate parts of their query - possibly quite large parts.)

[afs]

This should be considered alongside #76 which makes other changes to align with RDF 1.1.

About whether rdf-tests is uniformly RDF 1.1: #88.