I think that Pat summary in [1] is a fair starting point for considering the changes to the SPARQL draft. I see three main points requiring major (non-editorial) changes:

1) Simple patterns and complex queries.

The description of the semantics of a query expression should be understood in term of simple query pattern and subsequent algebraic operations on what we may call solution sets (it might be just tables, but bnodes complicate the picture). The current draft doesn't emphasise these two levels; however I'm fairly convinced that it's going to be just a rewording of what's already there. I gather that this first point isn't really controversial; since it's basically as they already understand SPARQL.

2) Bnodes

2a) Role of bnodes in answers.

I start from the assumption that they want them in a pattern solution. Currently, the document is ambiguous on whether the bnode name returned in a pattern solution is significant (i.e. the same of the corresponding bnode in the graph) or arbitrary. They kind of state that it's not significant, but they all expect that they should be exactly the names in the graph. I don't think that the alternative way proposed by Pat:

huddle: KB simply entails (KB union B(Q))

remote: KB simply entails B(Q)

and minimality is going to be pretty hairy (minimal answers would be those with bnodes from the graph itself... aargh). Still skolemisation seems to me the best option, since treating bnodes as URIs just in some cases looks to me more confusing.

2b) Role of bnodes in queries.

If names of bnodes are significant, they want to use them to formulate new queries. But they're not sure about it (in fact, the document is contradictory as Peter pointed out in [2]). I think we should prevent this. In general we want bnodes as existential variables in simple query patterns, because without them we loose expressiveness for querying languages able to "force" the existence of objects without any bnode (e.g. OWL-lite). Moreover, not knowing which are the names of bnodes in a graph makes the use of bnodes in queries rather confusing, since they'd behave differently when the name appear in the graph (constant vs exist. variable).

3) Minimality of answer sets.

Pattern solutions can be redundant or not according to the semantics of bnodes in answers. Note that our definition of redundancy is based on answer sets only, and *doesn't* depend on the graph. Pat's example in [1] seems to imply that the graph itself plays a role (although, I think that his example is more related to 2b above).

[1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0471

[2] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0477.html

Specific items affected by the changes in the editors working draft. http://www.w3.org/2001/sw/DataAccess/rq23/

* Pattern Solution
http://www.w3.org/2001/sw/DataAccess/rq23/#PatternSolutions

With entailment we don't need bindings for bnodes.

* Basic Graph Pattern
http://www.w3.org/2001/sw/DataAccess/rq23/#BasicGraphPatternMatching

Definition of 'matching' in terms of (some) entailment.

* Optional Pattern Matching
http://www.w3.org/2001/sw/DataAccess/rq23/#OptionalMatching

From the algebraic point of view it seems to be a left outer join; although this doesn't account for {{} OPTIONAL Q } = Q unless you do some tricks with the meaning of the empty pattern.

* Multiple Optional Graph Patterns
http://www.w3.org/2001/sw/DataAccess/rq23/#MultipleOptionals

With the outer join perspective, I'm pretty sure it should be:

{ Q OPTIONAL Q1 OPTIONAL Q2 } = {{ Q OPTIONAL Q1 } OPTIONAL Q2 }

* Ditch the whole GRAPH/NAMED thing (or push it in soma appendix).

* CONSTRUCT
http://www.w3.org/2001/sw/DataAccess/rq23/#construct

The definition is plain wrong, since you don't want to "RDF merge" bnodes coming from the graph, just the ones in the template:

CONSTRUCT { ?x :looks ?y } with answer set [?x/_:a,?y/:here], [?x/_:a,?y/:there]

results in the graph

_:a :looks :here . _:a1 :looks :there .

where the coreference on _:a is lost.