GH-284: Align TRIPLE and expression <<( )>> #285
Conversation
rubensworks
left a comment
rubensworks
left a comment
There was a problem hiding this comment.
Besides this (what I assume to be a) typo, LGTM.
spec/index.html
Outdated
| <a href="#constructGraph">CONSTRUCT</a> query form | ||
| allows <a data-cite="RDF12-CONCEPTS#dfn-rdf-triple">RDF triples</a>, and not | ||
| their germalization to | ||
| <a data-cite="RDF12-CONCEPTS#dfn-symmetric-rdf-triple">symmetric RDF triples</a>. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- 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...
- 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...
- 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.
|
@Tpt You raise a very good point. However, I think we can still merge this PR by tweaking the text a bit. |
|
I also prefer the current definition as the safer approach (i.e., not the definition in this PR). |
|
"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. |
|
@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? |
Co-authored-by: Ruben Taelman <[email protected]>
| allows <a data-cite="RDF12-CONCEPTS#dfn-rdf-triple">RDF triples</a>. | ||
| Any other | ||
| <a data-cite="RDF12-CONCEPTS#dfn-symmetric-rdf-triple">symmetric RDF triples</a> | ||
| will be omitted from the result. |
There was a problem hiding this comment.
I am not sure to understand this note, especially the Any other
connector. Do you mean that CONSTRUCT is allowed to emit symmetric RDF triples?
This goes against If any such instantiation produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in subject or predicate position, then that triple is not included in the output RDF graph.
in 16.2 CONSTRUCT.
There was a problem hiding this comment.
The note is unclear to me as well.
It seems to me to be two parts.
The first part is the first sentence, but I don't understand what was meant by "symmetric RDF triples" corresponding (or not) to "SPARQL triple patterns"?
The second part is the the latter two sentences. I think Any other should be Any. That at least makes these two sentences make sense.
| <a data-cite="RDF12-CONCEPTS#dfn-literal">literal</a>) | ||
| the function returns a triple term with these three elements. | ||
| and <code style="color:black">obj</code>, | ||
| where the predicate is |
There was a problem hiding this comment.
| where the predicate is | |
| where the predicate is an |
This closes #284.
Discussion: #283 (comment)
Make writing
<<( ... )>>the same as usingTRIPLEwith the same arguments.(The inverse is not permitted by the grammar -
TRIPLEcan have expressions, but expressions are not allowed in<<( ... )>>because there are no comma separators.)Preview | Diff