ericP: if variable is
introduced in one OPTIONAL and then appears in a second
OPTIONAL, then bindings from one do not constrain the other,
they only enhance it

<EliasT> i.e. + :a cc:license
"steal this book" .

ericP: this doesn't
happen "normally" because OPTIONAL is a binary operator and
text near OPTIONAL specifies [left-associativity] for
OPTIPONALs without other triples in between

ericP: but adding more
triples ends up with the factorial scenario

FredZ: One of the
points from the Chile paper is that SPARQL doesn't explicitly
consider precedence in main body of text - precedence is
implicit in the grammar.

FredZ: <something
else about disconnect between semantics and presentation of
semantics in document>

ericP: think we should
first decide how this SHOULD work before discussing how to
present how it works

<AndyS> "Better spec" is
bound by the length of the charter

<kendallclark> Yes. But we
have to answer and satisfy reasonable, novel claims about the
formal semantics of our language. That seems unavoidable.

<AndyS> defn of LEXICAL
assumes hard nulls ?

<kendallclark> My org -- not
speaking here as chair -- strongly wants a compositional
semantics for SPARQL. Lexical order sensitivity is a bad thing
in many ways, IMO.

<AndyS> FredZ: reorder of
peers should not matter

<AndyS> FredZ: nesting of
structures may indicate order

<kendallclark> And we'd
really like to be able to optimize RDF queries.

ericP: does the spec
need to deal with commutativity and associativity of operators
and the equivalences that fall out therefrom?

FredZ: SQL spec does
not

ericP: Would like to
define eveyrthing in term of lexical order and let lexical
indepdence fall out in some cases from logical properties of
operators (but the spec says nothing about these
clevernesses)