Consider bnode graph names in evaluation of Graph #221
Conversation
| the result is <var>R</var> | ||
| </pre> | ||
| <p>For every |x| that is | ||
| an <a data-cite="RDF12-CONCEPTS#dfn-IRI">IRI</a> or |
There was a problem hiding this comment.
| an <a data-cite="RDF12-CONCEPTS#dfn-IRI">IRI</a> or | |
| an <a data-cite="RDF12-CONCEPTS#dfn-IRI">IRI</a>, | |
| a <a data-cite="RDF12-CONCEPTS#dfn-blank-node">blank node</a> or |
Should the definition of the evaluation of "graph" mention blank nodes?
It isn't necessary because they come in via variables but:
- It more clearly indicates that literal and triple terms can not be used
- The intuition of variable substitution applies
There was a problem hiding this comment.
@afs your edit suggestion is incorrect. The x in Graph(x, P) may indeed be only an IRI or a variable; not a blank node. While the algebraic syntax is not explicitly defined in the spec, it is clear from the grammar of the user-facing syntax that there can be no blank node---see the GraphGraphPatternproduction:
[62] GraphGraphPattern ::= 'GRAPH' VarOrIri GroupGraphPattern
Should the definition of the evaluation of "graph" mention blank nodes?
It isn't necessary because they come in via variables but:
- It more clearly indicates that literal and triple terms can not be used
Cannot be used for what exactly?
If you mean that they cannot be used as the x in the new version of this definition, I think stating that x may be an IRI or a variable (as done in this PR) is sufficient.
If you mean that they cannot be used as bindings for the variable x (in case x is a variable), I don't think that saying something like this belongs in this definition; maybe better suited for the informal text in Section 13.3 Querying the Dataset. Also, it is not entirely correct to say that literals and term maps cannot be assigned to variable x in incoming solution mappings; such solution mappings would just not survive the Join within the foreach loop. Perhaps one thing to make this more obvious would be to extend the foreach-line of the algorithm from (current form)
foreach graph name gn in D
to
foreach graph name gn in D (recall that a graph name may be an IRI or a blank node)
Would that address your concern?
- The intuition of variable substitution applies
I am not sure what you mean by this comment.
There was a problem hiding this comment.
- It more clearly indicates that literal and triple terms can not be used
Cannot be used for what exactly?
As graph names.
It does not cause any harm to be a little bit more general here.
The 1.1 text says "foreach IRI i in D"; the new text puts in a link so the cue isn't there.
"foreach graph name gn in D"
- The intuition of variable substitution applies
I am not sure what you mean by this comment.
In TriG, GRAPH _:label { ... } is legal so one can think of the query as a trig pattern, like BGPs are turtle patterns.
The variable may, visually, be defined in the query close-by.
(Yes, this actually happens when the "graph" evaluation is joined with the rest of the group graph pattern.)
There was a problem hiding this comment.
- It more clearly indicates that literal and triple terms can not be used
Cannot be used for what exactly?
As graph names.
It does not cause any harm to be a little bit more general here.
The 1.1 text says "foreach IRI i in D"; the new text puts in a link so the cue isn't there."foreach graph name gn in D"
Now I understand your concern! I had a proposal related to that already in my previous comment: We may extend this line of the algorithm as follows.
"foreach graph name gn in D (recall that a graph name may be an IRI or a blank node)"
I think that should address your concern. Do you agree?
- The intuition of variable substitution applies
I am not sure what you mean by this comment.
In TriG,
GRAPH _:label { ... }is legal so one can think of the query as a trig pattern, like BGPs are turtle patterns.
Right.
Do you think my proposal for the previous point addresses this one as well? Otherwise, what else would you propose to do here?
There was a problem hiding this comment.
Picking up on @afs suggestion above...
| an <a data-cite="RDF12-CONCEPTS#dfn-IRI">IRI</a> or | |
| an <a data-cite="RDF12-CONCEPTS#dfn-IRI">IRI</a>, | |
| a <a data-cite="RDF12-CONCEPTS#dfn-blank-node">blank node</a>, or |
There was a problem hiding this comment.
@afs I have now pushed a commit (ad44a8b) with the change proposed above, extending the
"foreach graph name gn in D"
line of the algorithm to
"foreach graph name gn in D (recall that a graph name may be an IRI or a blank node)"
Does this address your concerns? Or do you still think it is better to extend the Graph operator such that its first argument can not only be an IRI or a variable but also a blank node? (I would still find that confusing because that deviates from the user syntax)
There was a problem hiding this comment.
@afs are you still planning to review this PR? Otherwise, I will merge it. It has approvals from all the other editors.
There was a problem hiding this comment.
Just noting that GRAPH _:blank (if it were legal) is always empty. Blank nodes treatment as non-distinguished variables happens in BGPs.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
This was discussed during the #rdf-star meeting on 19 June 2025. View the transcriptw3c/sparql-query#221 and w3c/sparql-query#227<gb> Pull Request 221 Consider bnode graph names in evaluation of Graph (by hartig) <gb> Pull Request 227 Adds explicit definition of the algebraic syntax (by hartig) olaf: I have two PRs on sparql-query that have been opened for a long time AndyS: does not look controversial |
This PR addresses #217 by extending the definition of how to evaluate GRAPH patterns such that it now also considers blank nodes as possible graph names in an RDF dataset.
Additionally, the PR:
Preview | Diff