13:46:26 RRSAgent has joined #sparql 13:46:26 logging to http://www.w3.org/2010/10/26-sparql-irc 13:46:33 Zakim has joined #sparql 13:46:42 Zakim, this will be sparql 13:46:43 ok, AxelPolleres; I see SW_(SPARQL)10:00AM scheduled to start in 14 minutes 13:47:15 my regrets, alas. :-( 13:47:19 agenda+ SELECT * 13:47:33 agenda- SELECT * 13:47:45 doesn't work it seems ;-) 13:47:48 NicoM has joined #sparql 13:47:54 agenda+ admin 13:48:14 agenda+ aggregates issues 13:48:31 agenda+ potentially bound/SELECT* 13:48:59 agenda+ test case approval 13:49:02 agenda? 13:49:33 item- 1 13:49:58 agenda? 13:50:14 remove agendum 1 13:50:19 agenda? 13:51:28 OlivierCorby has joined #sparql 13:53:13 NickH has joined #sparql 13:53:43 chair: Axel Polleres 13:54:00 regrets: Andy Seaborne 13:54:42 agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0156.html 13:54:56 SW_(SPARQL)10:00AM has now started 13:55:00 SW_(SPARQL)10:00AM has ended 13:55:02 Attendees were 13:55:09 alex, can you scribe? 13:55:45 Zaki, are you ok?!? 13:56:09 Zakim, you start end end our meeting 5min in advance... strange... 13:56:09 I don't understand you, AxelPolleres 13:56:30 SW_(SPARQL)10:00AM has now started 13:56:38 + +49.911.973.4.aaaa 13:56:39 +??P1 13:56:53 Zakim, ??P1 is me 13:56:53 +NickH; got it 13:57:12 not a lot of people here? 13:57:20 Zakim, +49 is me 13:57:20 +NicoM; got it 13:57:56 cbuilara has joined #sparql 13:58:28 +AxelPolleres 13:58:49 Zakim, who is on the phone? 13:58:51 On the phone I see NicoM, NickH, AxelPolleres 13:58:55 +kasei 13:59:01 +OlivierCorby 13:59:13 Zakim, mute me 13:59:19 kasei should now be muted 13:59:19 MattPerry has joined #sparql 13:59:44 +??P24 14:00:15 zaki, Zakim ??P24 is me 14:00:28 +MattPerry 14:00:29 Zakim ??P24 is me 14:00:38 Zakim, ??P24 is me 14:00:38 +cbuilara; got it 14:00:41 let's wait for 1-2 min for people to join still 14:00:55 +??P27 14:01:04 Zakim, ??P27 is me 14:01:04 +SteveH; got it 14:01:07 dialing in now.... 14:01:22 Zakim, who is on the phone? 14:01:23 On the phone I see NicoM, NickH, AxelPolleres, kasei (muted), OlivierCorby, cbuilara, MattPerry, SteveH 14:01:26 out of UK lines, again :( 14:01:40 still only one UK line? 14:01:47 +pgearon 14:01:48 dunno, not enough 14:01:50 ivan, sandro? 14:02:11 bglimm has joined #sparql 14:03:17 Zakim, who is on the phone? 14:03:17 On the phone I see NicoM, NickH, AxelPolleres, kasei (muted), OlivierCorby, cbuilara, MattPerry, SteveH, pgearon 14:03:56 bglimm, there's no UK lines :( 14:04:27 scribe: paul gearon 14:05:02 next agendum 14:05:04 AxelPolleres: same agenda as from last week 14:05:15 zakim, dial ivan-voip 14:05:15 ok, ivan; the call is being made 14:05:17 +Ivan 14:06:04 PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-10-19 14:06:46 RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-10-19 14:07:16 ivan: w3.org has problems... some attack 14:07:39 Yes, but it is always my private money. The university should pay for that! 14:07:44 AxelPolleres: next regular meeting 2nd November 14:07:46 Next regular meeting: 2010-11-02 @ 15:00 UK / 10:00 EDT (scribe: Alex Passant) 14:08:12 next agendum 14:08:39 topic: aggregate issues 14:08:39 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0040.html 14:08:43 AxelPolleres: some mail exchanged, mainly answered by Steve and Andy about how to deal with unbounds and aggregates 14:09:02 +bglimm 14:09:15 Zakim, mute me 14:09:15 AxelPolleres: variable which is GROUPed BY is potentially unbound, should there by an error or unbound 14:09:15 bglimm should now be muted 14:09:48 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0002.html 14:10:19 AxelPolleres: according to Andy, in ARQ there will be a separate group for unbound 14:10:57 SteveH: the idea is that the key for that group would be a symbol indicating an error 14:11:32 GROUP BY (?X+?Y) 14:12:10 GROUP BY ((?X+?Y) AS ?Z) 14:12:34 I thought we had agreed to support grouping by expressions(?) 14:12:48 SteveH: I don't think you can group by expressions. You can do it with a subquery that projects an expression 14:13:11 kasei, I'm not 100% sure 14:13:15 SteveH: if X and Y are both strings, then the evaluation will be an error, and all of those errors will fall into one group 14:13:18 current understanding is all errors and unbound would fall into one group 14:13:37 AxelPolleres: is that compliant with what SQL does? 14:13:47 Axel: is that compliant with SQL? 14:14:14 SteveH: SQL doesn't define this, I don't think. I can't remember offhand. SPARQL have more type errors than SQL because SQL is loosely typed and SPARQL is strongly typed 14:14:34 pgearon, other way round SQL = strong, SPARQL = weak -- ish 14:14:41 Axel: ListEval() in the algebra needs adaption, yes? 14:14:45 AxelPolleres: leave that with the editors. It will come back to the evaluation of list eval in the algebra 14:15:19 FYI: Oracle SQL treats Null as a distinct group 14:16:21 MattParry: just did a quick experiment of group by on a table with some null columns, and it came out as a separate group 14:16:23 good enough :) 14:16:25 ACTION: steve to implement the common understanding in ListEval() on unbound treated like errors 14:16:26 Created ACTION-328 - Implement the common understanding in ListEval() on unbound treated like errors [on Steve Harris - due 2010-11-02]. 14:17:02 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0041.html 14:17:26 order by parameter for group concat 14:17:26 AxelPolleres: recall that we'd agreed to put an order by parameter on group concat 14:18:00 ASC|DESC only or full expressions for order? 14:18:07 AxelPolleres: in reply to this, Steve and also Andy said that we'd allow ASC|DESC 14:18:18 Steveh: that's not my opinion 14:18:28 SteveH: too much for this version of the spec 14:18:53 (referring to full expressions for ordering) 14:19:26 SteveH: my proposal is to leave it as it is. No ORDER BY expression at all 14:19:43 AxelPolleres: I think that this would not be useful 14:20:01 AxelPolleres: disagree. Been using for a decade and have never needed ordering on this 14:20:01 Lee may have an opinion, he uses it a lot too 14:20:14 Zakim, who is on the phone? 14:20:14 On the phone I see NicoM, NickH, AxelPolleres, kasei (muted), OlivierCorby, cbuilara, MattPerry, SteveH, pgearon, Ivan, bglimm (muted) 14:20:55 AxelPolleres: don't want to close this issue until we have other opinions. Expect Lee and Andy will have opinions on this, and they're not here this week 14:20:59 q+ to speak against simple ordering 14:21:44 we'll also need limit 14:21:51 Options for group_concat: 1) no order_by 2) simple order_by 3) full ordering by expressions (e.g. order by second letter of a word, etc.) 14:22:05 simple order by would just be ASC|DESC 14:22:27 SteveH: concern that it won't meet all that many use cases, and we'll probably have full ordering in SPARQL 1.2 that may be different, and we don't want to have alternatives due to complexity 14:22:48 argumetn against 3) is too much work at t the moment. 14:23:08 1 for now 14:23:09 1 (punt until next time) 14:23:12 1 14:23:13 1 14:23:13 1 14:23:14 1 14:23:18 strawpoll... 1,2,3? 14:23:31 1 14:23:33 2 mildly, but can live with 1. 14:23:36 1 14:23:57 AxelPolleres: that's quite clear. We'll stick with no ORDER BY in group concat for the moment 14:24:04 current understanding is... let's stick with no ORDER BY 14:24:23 next agendum 14:24:23 next agendum 14:24:24 can we have a postponed thig for the next group? 14:24:31 q? 14:24:35 q- 14:24:39 ack steveh 14:24:43 next agendum 14:24:59 http://www.w3.org/2009/sparql/wiki/Potentially_bound 14:25:19 AxelPolleres: definition of "potentially bound" variables on the wiki 14:25:42 AxelPolleres: two things are ambiguous at the moment. First is, what is the meaning of "SELECT *" 14:26:22 AxelPolleres: the spec mentions SELECT * in 2 places 14:26:28 17.2.3 Converting Solution Modifiers 14:26:48 VS := list of all variables visible in the pattern 14:27:22 ... that's not clearly defined, but could use potentially bound variable definition 14:28:30 AxelPolleres: proposal to use "potentially bound" as the definition for SELECT * 14:28:56 doesn't this contradict a strawpoll earlier? 14:28:56 strawpoll, shall we go ahead with that definiition to define "SELECT *"? 14:30:20 P = { P1 } GROUP BY E1 ... En such that either there is an Ei of the form ?v or (E AS ?v) 14:30:51 SteveH: there's a clause in the Potentially Bound def, that refers to GROUP BY, and this means that GROUP BY affects SELECT * 14:31:18 SELECT * WHERE { ?x ?y ?z } GROUP BY ?x, ?y 14:31:30 Zakim, unmute me 14:31:30 bglimm should no longer be muted 14:31:57 q+ to ask why * is not just an abbreviation for all variables mentioned 14:32:07 SteveH: think that the previous strawpoll suggested that query should be an error 14:32:10 bglimm, quite 14:33:07 MINUS is a little tricky 14:33:10 bglimm: recall that was an error, since * refers to all variables, and ?z cannot be selected when it is not in the GROUP BY 14:33:24 "The syntax SELECT * is an abbreviation that selects all of the variables that could be bound in a query." 14:33:32 section 15.1.1 14:33:46 i think the current definition has some bugs in it. I'm in favor or using something like this, but probably not this exact text. 14:34:06 in particular, the definition for SERVICE seems wrong. 14:34:08 I agree with bglimm. I think * would refer to ?z and this must lead to an error 14:34:13 10.1 "The syntax SELECT * is an abbreviation that selects all of the variables in a query." 14:34:43 Zakim, unmute me 14:34:43 kasei should no longer be muted 14:34:44 but the SERVICE definition does not use potentally bound 14:34:49 http://www.w3.org/TR/rdf-sparql-query/#select 14:34:55 bglimm: I don't see why the definition needs to be complicated. Just refer to all variables, and then define errors in some cases 14:34:59 SELECT * FROM EMP GROUP BY job is an error in SQL 14:36:53 kasei: the defintion for SERVICE seems wrong as "SERVICE ?t {...}" alone won't mean ?t is potentially bound 14:37:08 Zakim, mute me 14:37:08 kasei should now be muted 14:37:09 SteveH: the first spec just says that SELECT * selects all the variables from the query 14:37:30 +q 14:37:38 ack bglimm 14:37:38 bglimm, you wanted to ask why * is not just an abbreviation for all variables mentioned 14:38:14 Zakim, mute me 14:38:14 bglimm should now be muted 14:38:52 it does need a bit of rewording, yes 14:39:18 bglimm, which is the same as not grouping, right? :) 14:39:29 kasei, well, it's the same as lots of groups of 1 14:39:36 yes, subquery might be a reason for the def to be more complicated 14:39:43 kasei, not grouping is one group of everything 14:40:06 paul: subquery SELECT * would mean also the variables in the subquery.. 14:40:29 according to the SPARQL 1 definition, yes 14:40:31 ok, right. I hope my main point was clear, though: it's a nice syntax shortcut. 14:41:07 we need to update the definition so that it does not "accidentally" refer to variables that are out of scope (ie in a subquery) 14:41:24 -NickH 14:41:33 SELECT * WHERE { ... SELECT ?X { ?X ? Y ...} }} 14:41:43 something like "all of the variables in this query, or it's subqueries" 14:41:44 would leave ?Y always unbound 14:42:16 I don't want ?Y to appear in SELECT * in that case 14:42:20 my feeling is that as soon as you get to that level of complexity * is pretty useless 14:42:31 yes, I agree with pgearon 14:42:35 I agree with Paul. It should only get ?x 14:42:45 +??P1 14:42:52 pgearon, how is that different from variables which aren't grouped? 14:42:54 Zakim, ??P1 is me 14:42:54 +NickH; got it 14:43:10 subqueries, and MINUS I think 14:43:18 perhaps 14:43:21 Nice use case: SELECT * WHERE { ... SELECT * { ?X ? Y ...} }} 14:43:40 SELECT * WHERE { ... SELECT ?X { ?X ? Y ...} }} 14:43:41 that should give ?x ?y IMO 14:43:44 variables (like ?y in the above query) are not in scope, whereas ungrouped variables are in scope, but not selectable 14:43:44 -OlivierCorby 14:44:06 strawpoll... +1 ?X only -1 ?X ?Y 14:44:08 +1 14:44:10 0 14:44:12 +1 14:44:14 +1 14:44:14 +1 14:44:18 +1 14:44:31 +OlivierCorby 14:44:38 I don't see how it could be otherwise. There's no point in having a SELECT clause in the subquery otherwise 14:44:50 yes 14:44:53 pgearon, huh? it's just sugar 14:45:00 +q 14:45:04 Zakim, unmute me 14:45:04 bglimm should no longer be muted 14:45:46 birte: "potentially bound" should only cover subqueries but not more... 14:45:46 agreed, "potentially bound" is not a good phrase, ambiguous 14:45:51 bglimm: the def should cover only the subquery case, don't want it too complicated 14:46:04 AxelPolleres: can you make a proposal please? 14:46:09 bglimm: OK 14:46:18 ACTION: birte to come up with a more minimalistic proposal for "*" than "potentially bound" 14:46:18 Created ACTION-329 - Come up with a more minimalistic proposal for "*" than "potentially bound" [on Birte Glimm - due 2010-11-02]. 14:49:00 birte, it seems that a stub for that is already in Section 17... 14:49:27 +1 for waiting for bglimm's proposed definition 14:50:17 AxelPolleres: another restriction on the use of SELECT expressions, which is where this definition of Potentially Bound was coming into play 14:50:22 "The new variable is introduced using the keyword AS; it must not already be potentially bound." 14:50:40 and I guess we'll have thesame restriction for BIND 14:50:50 this is to meet Andy's SAMPLE(?x) A ?x usecase I think 14:50:54 *AS 14:52:01 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0087.html 14:52:30 andy seems to indicate it's natural 14:52:31 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0101.html 14:52:33 +q 14:52:43 lee says it is forbidden in Glitter 14:54:14 pgearon: Andy will have a strong opinion here. Any conversation we have will be repeated once he comes back, so we shouldn't spend any further time on it 14:54:26 we can deal with the SAMPLE usecase by just saying that no two aggregate expression can project the same variable name 14:54:30 -q 14:54:31 as you said they're a different case 14:54:42 Problem is: "The new variable is introduced using the keyword AS; it must not already be potentially bound." Aggregates are not affected by this restriction 14:54:46 you=axel :) 14:55:56 I'll try 14:56:01 AxelPolleres: on test cases. Ask that anyone with a test case on the list, please fix wrt what was decided last time 14:56:02 sure 14:56:10 is there a summary of "what we decided last time"? I didn't really follow it. 14:56:22 bye all 14:56:44 bye 14:56:48 zakim, drop me 14:56:52 ok, that would help. the minutes weren't all that clear to me. 14:56:56 Axel: will try to include decisions from ;last time on test vocab into README.html 14:57:02 Ivan is being disconnected 14:57:04 AxelPolleres: summary from last time in the minutes, but hope to get this into html files before the end of the week 14:57:06 -Ivan 14:57:08 -MattPerry 14:57:12 -bglimm 14:57:22 -SteveH 14:57:28 please all try to update test cases accordingly, and send a mail to the list askign for approval, as you';re done. 14:57:29 -NicoM 14:57:31 -OlivierCorby 14:57:34 -kasei 14:57:35 adjourned 14:57:40 -cbuilara 14:57:40 -NickH 14:59:08 rrsagent, make records public 14:59:14 -AxelPolleres 14:59:18 -pgearon 14:59:20 SW_(SPARQL)10:00AM has ended 14:59:23 Attendees were +49.911.973.4.aaaa, NickH, NicoM, AxelPolleres, kasei, OlivierCorby, MattPerry, cbuilara, SteveH, pgearon, Ivan, bglimm 15:01:47 paul, guess you can just generate the minutes and the nstore the html locally to be sure it's not lost. 15:01:50 thanks! 16:03:26 OlivierCorby has left #sparql 16:14:52 ivan has joined #sparql 16:51:22 AxelPolleres has joined #sparql 18:41:06 pgearon_ has joined #sparql 19:06:23 bglimm has joined #sparql 19:43:14 bglimm has joined #sparql