Consider bnode graph names in evaluation of Graph

[hartig]

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:

• changes the layout style of the changed definition such that it is consistent with the style of the other definitions in this part of the spec
• removes the introduction of the notation Ω(x) from the beginning of Section 18.3 Basic Graph Patterns
  • (this notation was used only in the definition that this PR changes and it was also not really clear; I have replaced it by something better directly in the changed definition now)
• removes the notation D[i] from the beginning of Section 18.5.2 Evaluation Semantics
  • (this notation was also used only in the definition that this PR changes)
• removes the following paragraph which was placed directly below the changed definition but, in my opinion, doesn't really add anything (in fact, it is not even relevant because there can be no solution mapping that is in the result of more than one of the joins that feed into the union in the given algorithm)---but if you think it is useful to keep that paragraph, let me know and I will restore it!

The evaluation of graph uses the Union operator. The multiplicity of a solution mapping is the sum of the multiplicities of that solution mapping in each Join operation.

---

Preview | Diff

[afs]

Suggested change

	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:

1. It more clearly indicates that literal and triple terms can not be used
2. The intuition of variable substitution applies

[hartig]

@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:

1. 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?

2. The intuition of variable substitution applies

I am not sure what you mean by this comment.

[afs]

1. 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"

2. 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.)