See also: IRC log
<kendallclark> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0185.html
<kendallclark> Minutes from 20 June meeting
<kendallclark> PROPOSED to accept them as a record of last week's meeting
<kendallclark> 2nd, DanC
<kendallclark> RESOLVED
KC: no meeting next week nor the rest of July...
PROPOSED: to meet 1 Aug...
... to meet 1 Aug 14:30Z, KC to chair...
EricP: I'm at risk for 1 Aug.
PatH: I'm at risk due to travel 1 Aug
FredZ: I'm at risk 1 Aug
KC: I'll find a scribe or something...
<kendallclark> RESOLVED
RESOLUTION: to meet to meet 1 Aug 14:30Z, KC to chair.
<scribe> ACTION: FredZ to write an email w/ a test for the test suite re: { P1 } UNION { P2 } OPTIONAL { P3 } [DONE] [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action01]
PatH: I was surprised that putting a filter between two triples made [missed]
FredZ: yes, that's why I'm raising it.
"3. Same dataset, slightly revised query:"
<kendallclark> That definitively raises (or reopens) some issue... Not sure which.
<kendallclark> I mean, Fred's 3b test
several regard Fred's "3. Same dataset, slightly revised query:" as surprising.
PatH: I think we discussed this and the scope of _:a is the {}s.
FredZ: that's not the way I read the definition of basic graph matching
EricP: is it enough to move the filters to the end?
FredZ: we could specify that, I suppose
<kendallclark> I don't recall discussing that at all...
(I have a vague memory of discussing it)
(darn; Fred just read from where in the spec?)
<kendallclark> Section 4.3...?
(the TOC seems to be hosed; http://www.w3.org/TR/rdf-sparql-query/#matchDEntail doesn't got to 4.3)
FredZ: I see "Any solution for the group graph pattern that can satisfy all the graph patterns in the group is valid, independently of the order that may be implied by the lexical order of the graph patterns in the group."
KC: that should be integrated with [missed], at least, yes?
EricP: so it should show up in a formal definition...?
<ericP> the extracted definitions
FredZ: I understood all the stuff outside the boxes to be commentary
<kendallclark> FredZ: Spell out more clearly how to apply 4.3
FredZ: consider { {?x <v1> _:a .} FILTER (isIRI (?x)) {?x <v2> _:a} }... does 4.3 imply that you can erase the inner {}s?
EricP: doesn't the grammar make that clear? I guess there isn't a strong statement about the connection to the grammar... would that help?
FredZ: indeed! that's been my main point
<kendallclark> i.e., asking that they be made more explicit
EricP: recall the A OPT B C OPT D thing... [?]
(EricP and FredZ discuss at a rate that exceeds the scribe's capacity)
<kendallclark> I'm prepared to make a new issue, evalOrder, to track this bit... I think it's may be more than editorial.
PatH: the optional thing could be
phrased more directly, [...], without "otherwise"
... seems to me that the basic graph match semantics are
attached to GraphPattern, which includes FILTERs...
Jeen: how about just expanding the scope of blank nodes to the whole query?
FredZ: that would be intuitive;
it's a question of defining Basic Graph Pattern matching so
that it works...
... I'd prefer to introduce Existential quantifiers so that the
user can say what the scope is.
PatH: I take the spec to say that {}s do that now.
FredZ: OPTIONAL always has {}s around the 2nd arg... so it's different? [?]
PatH: yes.
FredZ: users are going to find that a little wierd...
PatH: yes, users who aren't familiar with blank nodes are going to find them wierd...
FredZ: the problem is that the RDF Primer explains blank nodes as a solution to the problem that not everything is a binary relation...
<kendallclark> FredZ does a perfectly good impression of TimBL's argument for Turtleization of our syntax! :)
FredZ: so [something about
copy/paste and OPTIONAL and something breaking, a very
interesting case that I hope Fred or somebody will capture in
email]
... in SPARQL, ?var is like a forall in FOPC and _:var is like
exists FOPC... it would make sense to make the quantification
scope explicit
PatH: it's explicit enough for me with the {}s
EricP: [something about SQL]... I don't see how SPARQL has existentials...
PatH: a query is like a negated formula, so existentials act like existentials
FredZ: I don't see the negation...
PatH: well, that's a simplification... the query is on the point end... KB =?=> Query
FredZ: entialment is |=? why do we prefer that to |- ?
PatH: |= is logical entialment,
|- is provability; semantic vs syntactic...
... |= vs |- isn't the main thing; the main thing is just plain
old scoping
FredZ: I think having explicit existential quantifiers would help
EricP: FredZ, I'm not clear on what you're after; if there was just one scope for blank nodes...
<FredZ> select ?x where { (exists _:a) ?x <v> _:a OPTIONAL { _:a <v1> <b> }}
<ericP> apologies for not respecting the queue
DanC: I don't like having multiple scopes for blanknodes; I understand this came from the rdfSemantics issue, when I was trying not to think to hard about what I liked and what I didn't like
<kendallclark> I don't like that the people who seem to be thinking really hard and deeply about this stuff don't agree!
PatH: I think the language currently has the expressiveness you're asking for, without that syntax, Fred
<kendallclark> I'm not entirely sure that many of these semantic issues matter; deciding one way or the other is often a coin toss. What's especially troubling is that we don't seem to have a document that reduces the choices sufficiently clearly enough. :<
<patH> fwiw, scoping bound variables is one of the very few things that Alonzo Church got wrong in print.
<kendallclark> DanC: What's the cost of just making one scope for blank node identifiers?
PatH: I don't think there's one best solution... every design has something that looks broken...
<kendallclark> PatH: Seem to recall that it broke some folks intuitions in some cases.
<ericP> ASK { GRAPH <x> { ?a ?b _:a } GRAPH <y> { ?x ?y _:a }
<ericP> }
what's complicated about that, ericP? there are other cases where it's implementation-dependent whether parsing a file twice yields disjoint bnodes or not
<LeeF> I've found the current bnode scoping to be very convenient when writing code that generates SPARQL queries - clearly not a first-rate argument in favor, but just a datapoint.
<patH> lee, that means you know what hte curent scoping is, right?
<LeeF> Yes, I know what the current scoping is.
<LeeF> At least, I'm pretty sure I know =)
<jeen> according to the spec it's the BGP. See section 2.8.3, first line. right?
<LeeF> That's been my take on it.
<jeen> ...and according to section 2.5.4 the filter does not 'split' the bgp. I think I'm lost about what the issue is ;)
KC: so yes, let's turn these test case sketches into test cases and collect some data about how implementors have interpreted the spec
<patH> 2.8.3 first line says scoped to the *query*, not BGP.
<scribe> ACTION: EricP to turn FredZ's test case sketches into tests. http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0171.html [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action02]
<jeen> ah. I was looking the editor's draft patH
<jeen> my mistake
<patH> Ah, yes, I am behind current curve, thanks.
<patH> No, mine. Lets us use the absolutley most recent draft.
<scribe> ACTION: EliasT to turn C2.38 in PFPS's message into a test case [CONTINUES] [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action03]
(Elias might have done his part, but we haven't look at it)
<scribe> ACTION: KendallClark to reopen punctuationSyntax to take up commas in SELECT clause. [CONTINUES] [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action04]
<FredZ> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0176.html
-> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0176.html # formal semantics of OPT operator Fred Zemke (Friday, 23 June)
<LeeF> Elias says he did do his action and sent an email about it
FredZ: I wrote a proposal for semantics of OPTIONAL; Andy pointed out that it didn't handle a case; indeed, he's right. 0176 is my reply at that point
Fred: oops; typo in point 1; "S solves B, and there exists a restriction of B that solves A." [scribe not sure he got that]
KC: I think Andy is working on edits in this area
FredZ: so the editor doesn't always wait for a WG decision?
KC: right; sometimes the WG makes a decision based on a proposal from the editor
<kendallclark> I think we have significant schedule problems, actually. :<
FredZ: hmm... schedule concerns... I'm less available in September
KC: acknowledged.
<kendallclark> PROPOSED to ADJOURN
<scribe> ACTION: DanC to review PFPS's comments for more test cases [CONTINUES] [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action05]
<scribe> ACTION: EliasT to respond to Mark Baker's comments re: MIME type as we just resolved [DONE] [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action06]
<scribe> ACTION: take up new issue concatenated nestedOptional [CONTINUES] [recorded in http://www.w3.org/2006/06/27-dawg-minutes.html#action07]