GH-284: Align TRIPLE and expression <<( )>>

[afs]

This closes #284.

Discussion: #283 (comment)

Make writing <<( ... )>> the same as using TRIPLE with the same arguments.

(The inverse is not permitted by the grammar - TRIPLE can have expressions, but expressions are not allowed in <<( ... )>> because there are no comma separators.)

---

Preview | Diff

[rubensworks]

Besides this (what I assume to be a) typo, LGTM.

[Tpt]

Maybe state that the generalized triples are discarded by CONSTRUCT? The sentence sounded a bit weird to me, stating the issue but not telling what is the expected behavior.

[afs]

Good idea.

[Tpt]

I think we are overlooking one problem, symmetric triple term have impact on output outside of CONSTRUCT. What is the result of the following query?

PREFIX ex: <http://example.com/> .
SELECT (<<( "1" ex:equal "1" )>> AS ?t) {}

it is a single solution with the symmetric triple term <<( "1" ex:equal "1" )>> or is it no solution?

I see three way forward here:

1. return the symmetric triple term. It means allowing symmetric triple term in SPARQL output formats. Hence, they do not contain only valid RDF terms anymore...
2. do not return the invalid RDF triple term but keep it in internal solutions. But it means now that SELECT removes some tuples used internally, leading to impact on subqueries, unexpected behaviors for the users...
3. not merge this MR and prevent symmetric triple term to be included in solutions. This is the status quo.

I tend to prefer option 3, it avoids regrettable consequences and allow us to change our mind in a future version of SPARQL. It seems like the "safe" choice.

[rubensworks]

@Tpt You raise a very good point.
Keeping the old behaviour seems like a clean and safe approach to me as well.

However, I think we can still merge this PR by tweaking the text a bit.
So we could keep the old definition, but for implementors that want to support symmetric RDF, we could introduce this separate interpretation of what is allowed as input to TRIPLE().

[hartig]

I also prefer the current definition as the safer approach (i.e., not the definition in this PR).

[TallTed]

"Symmetric RDF" is not RDF, and must not be represented as if it were.

Else, users will try to load exports/dumps of Symmetric RDF into (non-Symmetric) RDF stores, with predictable failure to find all their triples in place upon completion and/or errors along the way.

Similarly, users who become accustomed to working with Symmetric RDF will run into all sorts of walls when using (non-Symmetric) RDF tools.

Especially there will be new issues arising when trying to use Federated SPARQL with any combination of SPARQL engines supporting Symmetric RDF and (non-Symmetric) RDF.

I am not 100% -1, lie down in the road, on permitting RDF store and SPARQL engine vendors to build in switches that allow Symmetric RDF to be loaded and/or queried and/or output, but there must be a way to trumpet that they are acting in such fashion, to minimize the issues that arise down the road.

Perhaps new media types are warranted.

[hartig]

@TallTed 's concerns are obviously not something specific to the SPARQL folks here, but more generally for the WG at large. Now, in this sense, didn't we already have a vote against symmetric RDF as the way RDF 1.2 will be?