Working with named graphs gets complicated fast

[dbooth-boston]

"SPARQL queries getting more complicated than necessary.

Most notably: The lack of persistent blank node identifiers for followup
queries. I know some triples stores can do this but it should really be
supported by all of them.

working with named graphs gets complicated quick - like adding a
{ GRAPH ?graph { } } block for every bit of info that may come from a different
graph."

https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0275.html

[dbooth-boston]

In re-reading the original comments from which I created this issue, I am now thinking that it should have been recorded as two separate issues, so I'm breaking it apart and putting the "composition of named graphs" into #57.

[rubensworks]

working with named graphs gets complicated quick - like adding a
{ GRAPH ?graph { } } block for every bit of info that may come from a different
graph."

Adopting the N-Quads syntax for quads may be a good solution for this.

SELECT * WHERE {
  GRAPH ?g {
    ?s ?p ?o
  }
}

=>

SELECT * WHERE {
  ?s ?p ?o ?g
}

A TriG-like syntax might not work out, as it may conflict with the current usage of {}.

[afs]

Removing "SPARQL: " on transferred issue.