Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-11-02
From SPARQL Working Group
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
16:22:33 <RRSAgent> RRSAgent has joined #sparql 16:22:33 <RRSAgent> logging to http://www.w3.org/2009/11/02-sparql-irc 16:26:59 <LeeF> LeeF has joined #sparql 16:27:04 <LeeF> hi everyone 16:27:37 <LeeF> zakim, who's on the phone? 16:27:43 <Zakim> Zakim has joined #sparql 16:27:43 <AxelPolleres> trackbot, start meeting 16:27:46 <trackbot> RRSAgent, make logs world 16:27:48 <trackbot> Zakim, this will be 77277 16:27:48 <Zakim> ok, trackbot; I see SW_SPARQL(TPAC)11:30AM scheduled to start in 3 minutes 16:27:49 <trackbot> Meeting: SPARQL Working Group Teleconference 16:27:49 <trackbot> Date: 02 November 2009 16:27:51 <LeeF> zakim, this is sparql 16:27:51 <Zakim> ok, LeeF; that matches SW_SPARQL(TPAC)11:30AM 16:27:59 <LeeF> Meeting: SPARQL Face to Face Meeting #2 Day 1 16:28:06 <AxelPolleres> Zakim, who is on the phone? 16:28:06 <Zakim> On the phone I see +1.408.988.aaaa 16:28:26 <AxelPolleres> Zakim, aaaa is TPAC_SPARQL 16:28:26 <Zakim> +TPAC_SPARQL; got it 16:28:59 <AxelPolleres> Zakim, TPAC_SPARQL has LeeF, AxelPolleres, SteveH, kasei 16:28:59 <Zakim> +LeeF, AxelPolleres, SteveH, kasei; got it 16:29:58 <AxelPolleres> Zakim, TPAC_SPARQL has DaveBeckett 16:29:58 <Zakim> +DaveBeckett; got it 16:30:16 <LeeF> Guest: Dave (dajobe) Beckett 16:30:18 <DaveB> DaveB has joined #sparql 16:30:28 <LeeF> zakim, DaveBeckett, is DaveB 16:30:28 <Zakim> sorry, LeeF, I do not recognize a party named 'DaveBeckett,' 16:30:31 <LeeF> zakim, DaveBeckett is DaveB 16:30:31 <Zakim> sorry, LeeF, I do not recognize a party named 'DaveBeckett' 16:30:41 <LeeF> zakim, TPAC_SPARQL has dajobe 16:30:41 <Zakim> +dajobe; got it 16:30:48 <LukeWM_> AndyS_, are you dialing in from the UK? 16:31:28 <bglimm> How can I dial in? 16:31:38 <LukeWM_> I can't seem to get through on the usual number 16:31:42 <bglimm> The normal UK number does not work 16:32:36 <LeeF> hmm 16:32:39 <LeeF> zakim, code? 16:32:39 <Zakim> the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), LeeF 16:32:47 <LeeF> is that the number you're trying? 16:32:50 <bglimm> yes 16:32:50 <LukeWM_> yes 16:32:56 <LeeF> zakim, please stop being a twit 16:32:56 <Zakim> I don't understand 'please stop being a twit', LeeF 16:33:01 <bglimm> but there is just a constant beep 16:33:04 <pgearon> pgearon has joined #sparql 16:33:10 <AxelPolleres> AxelPolleres has changed the topic to: http://www.w3.org/2009/sparql/wiki/Agenda-F2F2 16:34:06 <Zakim> + +1.540.412.aabb 16:34:07 <AndyS_> LukeWM_, can't dial in today - maybe tomorrow. 16:34:16 <bglimm> :-( dial in does not work 16:34:35 <pgearon> zakim, +1.540.412.aabb is me 16:34:35 <Zakim> +pgearon; got it 16:34:36 <LukeWM_> AndyS, Ah, OK, hopefully the number'll be working by then. 16:34:49 <LukeWM_> hope your first day is going well :) 16:37:02 <LukeWM_> nope 16:37:14 <bglimm> no 16:38:46 <LeeF> Axel is going to try to knock some heads together and sort this out 16:39:02 <bglimm> ok 16:39:21 <LukeWM_> OK, thanks. Good luck with the head knocking Axel. 16:43:13 <AxelPolleres> ran over to registration... 16:43:15 <SteveH> SteveH has joined #sparql 16:43:22 <AxelPolleres> ... seems they can't help immediately 16:43:45 <AxelPolleres> any chance you can dial the us number? 16:44:09 <AxelPolleres> or the french? :-) 16:44:19 <bglimm> Hm, I am not sure how expensive that will be... 16:44:27 <bglimm> I'll try the french 16:45:15 <Zakim> + +44.186.528.aacc 16:45:28 <LeeF> zakim, aacc is bglimm 16:45:28 <Zakim> +bglimm; got it 16:45:29 <bglimm> Zakim, +44.186.528.aacc is me 16:45:30 <Zakim> sorry, bglimm, I do not recognize a party named '+44.186.528.aacc' 16:45:32 <AxelPolleres> Zakim, TPAC_SPARQL has csma 16:45:32 <Zakim> +csma; got it 16:45:37 <bglimm> Zakim, mute me 16:45:37 <Zakim> bglimm should now be muted #16:45:53 <dajobe> observers: Dave Beckett (dajobe) 16:46:02 <dajobe> guest: Christian (csma) de Saint Marie 16:46:31 <LeeF> dajobe: I invented the word "SPARQL" and am responsible for rasqal 16:46:32 <dajobe> ... works for ibm 16:46:39 <LukeWM_> AxelPolleres, I can only dial the UK number I'm afraid. 16:47:21 <dajobe> Christian: know people who will be developing RIF for sparql - CTIC 16:48:08 <LeeF> Update on UK number - the UK number is through a 3rd party and the issue has been reported to them but we don't have an ETA of when it will be fixed 16:48:13 <dajobe> we're still doing introductions and I'm going to scribe 16:48:27 <dajobe> Lee intro 16:48:32 <bglimm> yes 16:48:36 <AxelPolleres> axel: will check with CTIC what's their status re: rif, they aren't at least not actively contributing up to this point yet. 16:48:40 <kasei> bglimm, the problem has been reported, but no estimate on when it might be fixed 16:48:40 <bglimm> just reading 16:49:00 <dajobe> Lee: try to get as much done as we can, may be a little handstrung by [low] attendance 16:49:23 <dajobe> will use mailing list to report on discussion on topics that need wider scope 16:49:36 <dajobe> otherwise will try to make decisions based on consensus, need to move forward 16:49:43 <dajobe> agenda 16:49:54 <dajobe> http://www.w3.org/2009/sparql/wiki/Agenda-F2F2 16:50:04 <dajobe> axel: query related issues 16:50:11 <dajobe> in the morning 16:50:20 <dajobe> two main points : aggregate, sub queries 16:50:27 <dajobe> are theer some issues we can close now? 16:50:35 <dajobe> lee: list of issues we can close a few weeks ago 16:51:01 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0419.html 16:51:28 <csma> csma has joined #sparql 16:51:33 <dajobe> axel: reviewing above 16:51:36 <LeeF> http://www.w3.org/2009/sparql/track/issues/3 16:51:52 <dajobe> axel: seems to have aggreement on #3 16:52:19 <dajobe> SteveH: may benefit from a keyword but it didn't seem to be too pupular 16:52:25 <dajobe> ... line noise feel from lots of use of {}s 16:53:08 <dajobe> ... optional WHERE didn't help 16:53:18 <dajobe> ... but no other support on that new keyword idea 16:53:18 <LeeF> PROPOSED: Resolve [http://www.w3.org/2009/sparql/track/issues/3 Subquery 16:53:18 <LeeF> syntax (e.g. mandatory curly braces)] by requiring curly braces around 16:53:18 <LeeF> subqueries and without introducing a keyword. 16:53:43 <AxelPolleres> Objections? 16:54:00 <LeeF> PROPOSED: Resolve [http://www.w3.org/2009/sparql/track/issues/3 Subquery syntax (e.g. mandatory curly braces)] by requiring curly braces around subqueries and without introducing a keyword. 16:54:09 <LeeF> RESOLVED: Resolve [http://www.w3.org/2009/sparql/track/issues/3 Subquery syntax (e.g. mandatory curly braces)] by requiring curly braces around subqueries and without introducing a keyword, no objections or abstentions 16:54:19 <dajobe> issue #4 16:54:25 <Zakim> -bglimm 16:54:56 <kasei> Zakim, who is on the phone? 16:54:56 <Zakim> On the phone I see TPAC_SPARQL, pgearon 16:54:57 <Zakim> TPAC_SPARQL has csma 16:55:02 <bglimm> hm, I'll try to dial in again 16:55:13 <dajobe> axel: have to name all the variables 16:55:38 <dajobe> and mention in the projection of the subquery 16:55:44 <dajobe> for bottom up approach 16:55:54 <Zakim> +bglimm 16:56:01 <bglimm> Zakim, mute me 16:56:02 <Zakim> bglimm should now be muted 16:56:36 <dajobe> axel: for ask subqueries this migh tbe aproblem, and want to have bindings come in 16:56:41 <dajobe> admin pause as we re-call phone #16:56:53 <Zakim> -TPAC_SPARQL 16:56:53 <bglimm> ok 16:56:55 <Zakim> -bglimm 16:57:09 <LeeF> zakim, dial suiteA 16:57:09 <Zakim> I am sorry, LeeF; I do not know a number for suiteA 16:57:11 <LeeF> zakim, dial suite A 16:57:11 <Zakim> I don't understand 'dial suite A', LeeF 16:57:15 <AxelPolleres> Zakim, dial Suite-A 16:57:15 <Zakim> I am sorry, AxelPolleres; I do not know a number for Suite-A 16:57:32 <Zakim> -pgearon 16:57:33 <Zakim> SW_SPARQL(TPAC)11:30AM has ended 16:57:34 <Zakim> Attendees were +1.408.988.aaaa, LeeF, AxelPolleres, SteveH, kasei, DaveBeckett, dajobe, pgearon, +44.186.528.aacc, bglimm, csma 16:57:58 <LeeF> pgearon, bglimm, sorry, working through our technical difficulties 16:58:01 <dajobe> we're still doing phone stuff here 16:58:02 <LeeF> zakim, dial prospectorA 16:58:02 <Zakim> I am sorry, LeeF; I do not know a number for prospectorA 16:58:05 <LeeF> zakim, dial prospector_A 16:58:05 <Zakim> I am sorry, LeeF; I do not know a number for prospector_A 16:58:08 <LeeF> zakim, dial suite_A 16:58:08 <Zakim> I am sorry, LeeF; I do not know a number for suite_A 16:58:26 <dajobe> axel's recalling the bridge 16:58:30 <Zakim> SW_SPARQL(TPAC)11:30AM has now started 16:58:36 <Zakim> +HCLSf2f 16:58:37 <LeeF> bglimm, pgearon, we're back online 16:58:41 <bglimm> ok 16:58:51 <LeeF> zakim, HCLSf2f is TPAC_SPARQL #16:58:51 <Zakim> +TPAC_SPARQL; got it 16:59:22 <dajobe> back to meeting 16:59:23 <dajobe> issue #4 #16:59:28 <LeeF> zakim, TPAC_SPARQL has SteveH, kasei, leef, dajobe, cdsm 16:59:28 <Zakim> +SteveH, kasei, leef, dajobe, cdsm; got it 16:59:37 <dajobe> axel: not sure what that means till we decide what a subquery is 16:59:38 <Zakim> +pgearon 16:59:46 <Zakim> +bglimm 16:59:53 <dajobe> kasei: not sure what ask sub queries are 16:59:53 <bglimm> Zakim, mute me 16:59:53 <Zakim> bglimm should now be muted 16:59:55 <Zakim> -bglimm 17:00:15 <dajobe> kasei: would use ask subquery for ASK NOT EXISTS? 17:00:32 <dajobe> axel: have an issue wehter you would be allowe SELECT queries in FILTER to get 1 value 17:00:48 <dajobe> LeeF: lets close this one for now and revisit if necesasr 17:01:31 <SteveH> bglimm, yeah, it's not working too well 17:01:54 <LeeF> PROPOSED: Resolve [http://www.w3.org/2009/sparql/track/issues/4 What is the variable scope between main queries and subqueries?] by noting that only variables projected from a subselect are visible outside the subselect and that all other variables and all blank nodes within the subselect are local to the subquery. 17:02:44 <dajobe> SteveH: wondering about blank nodes, cose they are graphs coped 17:02:53 <dajobe> ... already a bit wierd, this isn't any worse (paraphrasing) 17:03:02 <bglimm> I think I give up dialing in. It now complains about my� handset, but it is ok. I can call my mobile with it at least 17:03:18 <dajobe> pgearon: fine 17:03:22 <LeeF> RESOLVED: Resolve [http://www.w3.org/2009/sparql/track/issues/4 What is the variable scope between main queries and subqueries?] by noting that only variables projected from a subselect are visible outside the subselect and that all other variables and all blank nodes within the subselect are local to the subquery, no objections or abstentions 17:03:51 <dajobe> axel: next issues are for subqueries - #5 17:03:54 <dajobe> issue #8 17:04:14 <dajobe> http://www.w3.org/2009/sparql/track/issues/8 17:04:21 <dajobe> What determines the RDF dataset for subqueries? 17:04:31 <dajobe> lee: people same to agree it uses same dataset as parent 17:04:40 <dajobe> axel: propose close with previous agreement 17:05:02 <LeeF> PROPOSED: Close ISSUE-8 noting consensus that subqueries inherit the parent query's dataset and cannot have FROM & FROM NAMED clauses of their own 17:05:16 <LeeF> RESOLVED: Close ISSUE-8 noting consensus that subqueries inherit the parent query's dataset and cannot have FROM & FROM NAMED clauses of their own, no objections or abstentions 17:05:44 <dajobe> axel: inforamlly agreed on explciit grouping 17:05:53 <dajobe> issues #11 #12 17:06:18 <dajobe> grammar cannot now detect between agg function and regular in projection 17:06:24 <dajobe> if cna't tell difference, could not enforce this 17:06:52 <dajobe> implicit/default can be one big group, group by 1 17:07:01 <dajobe> SteveH: lean twoards sql approach - 1 big group 17:07:24 <dajobe> having to write GROUP BY 1 would be annoying if you had an agg function there 17:07:40 <dajobe> issue is about IMPLICIT group 17:08:45 <dajobe> SELECT ?bar and I don't have GROUP BY ?bar then it is implicitly... 17:09:08 <dajobe> looking at first example in http://www.w3.org/2009/sparql/track/issues/11 17:11:00 <dajobe> proposal is 'group by 1' default and otherwise you have to be explicit 17:11:18 <dajobe> ... prohibit to project on functions or funcitons of varioables that are not mentioned in the group by 17:12:03 <LeeF> PROPOSED: In the absence of a GROUP BY clause, the entire solution set acts as a single group 17:12:13 <LeeF> RESOLVED: In the absence of a GROUP BY clause, the entire solution set acts as a single group 17:13:52 <dajobe> swh: you can't pass a aggregated variable into a scalar function, or project it 17:14:29 <LeeF> PROPOSED: It's prohibited to project a variable, V, or a scalar function on a variable, V, if V is not included in the GROUP BY clause 17:14:39 <LeeF> PROPOSED: In an aggregate query, tt's prohibited to project a variable, V, or a scalar function on a variable, V, if V is not included in the GROUP BY clause 17:14:49 <LeeF> PROPOSED: In an aggregate query, it's prohibited to project a variable, V, or a scalar function on a variable, V, if V is not included in the GROUP BY clause 17:15:44 <LeeF> PROPOSED: In an aggregate query, you can't project an expression, E, unless that expression is a GROUP BY term 17:17:25 <dajobe> discussing whether to have GROUP BY ?var or GROUP BY expr(.) 17:17:33 <dajobe> and then writing the rules 17:17:42 <AxelPolleres> axel: note from the viewpoint of expressivite group by expressions aren't necessary, grouping by variables + subqueries/project expressions seem sufficient 17:19:22 <LeeF> kasei: what about doing aliasing in the GROUP BY clause ? 17:19:39 <dajobe> lots of choices here 17:19:58 <dajobe> 1. do it like sql 17:20:02 <dajobe> drop requirements for sample 17:20:17 <dajobe> 2. require the same syntactic form which is grouped & projected 17:20:23 <dajobe> 3. only allow group by ?var 17:20:58 <dajobe> 4. aliasing in group by (GROUP BY Expr as ?var) 17:21:01 <dajobe> - 17:21:50 <dajobe> #4 would look wierd still.. but may still require forbidding functions over agg vars 17:21:57 <dajobe> in the projection 17:22:02 <dajobe> so it would be like #3 then 17:22:12 <AxelPolleres> axel: 4. seems to imply similar restrictions as 3. 17:23:08 <dajobe> SteveH: propose # for now 17:23:14 <dajobe> and use subqueries to get expressions 17:24:48 <dajobe> lee: want to add to issue, get feedback from group by expr impl 17:24:56 <dajobe> kasei: I do this but don't do a lot of erro checking (!) :) 17:25:40 <AxelPolleres> zakim, who is on the phone? 17:25:40 <Zakim> On the phone I see TPAC_SPARQL, pgearon 17:25:41 <Zakim> TPAC_SPARQL has SteveH, kasei, leef, dajobe, cdsm 17:25:42 <LeeF> ACTION: Steve to summarize 4 options relating to grouping by expressions on the mailing list and solicit information on what existing implementations do 17:25:42 <trackbot> Created ACTION-130 - Summarize 4 options relating to grouping by expressions on the mailing list and solicit information on what existing implementations do [on Steve Harris - due 2009-11-09]. #17:27:06 <Zakim> -TPAC_SPARQL 17:27:08 <AxelPolleres> zakim, dial suite_a 17:27:08 <Zakim> ok, AxelPolleres; the call is being made 17:27:09 <Zakim> +Suite_a 17:27:14 <dajobe> we have RalphS in da house 17:27:17 <SteveH> SELECT ?x WHERE { { SELECT (?x + ?y) AS ?group WHERE { ?x :foo ?y } GROUP BY ?group } - or soemthing in that space 17:27:37 <LeeF> zakim, drop Suite_a 17:27:37 <Zakim> Suite_a is being disconnected #17:27:38 <Zakim> -Suite_a 17:28:16 <dajobe> it dailled the wrong number we think 17:28:21 <dajobe> .. looking at query 17:28:53 <AxelPolleres> steve your query misses a t least one } 17:28:59 <SteveH> yeah :-/ 17:29:01 <dajobe> SteveH: the above is how you would do it , if we didn't allow group by expr 17:29:18 <dajobe> there is a crucial } missing, hold on 17:29:55 <dajobe> .. still no phone working, redialling in 17:30:12 <dajobe> [anyone want to write a sparql IRC validator ?] #17:30:14 <Zakim> +TPAC_SPARQL 17:31:28 <dajobe> 11, 12 already mentioned 17:31:30 <SteveH> SELECT ?group 17:31:30 <SteveH> WHERE { 17:31:30 <SteveH> { 17:31:31 <SteveH> SELECT ?x+?y AS ?group 17:31:31 <SteveH> WHERE { 17:31:31 <SteveH> ?x :foo ?y . 17:31:33 <SteveH> } 17:31:34 <SteveH> } GROUP BY ?group 17:31:37 <SteveH> } 17:31:51 <dajobe> axel: no more query-related ones we can close, it seems 17:32:08 <dajobe> #12 17:32:12 <dajobe> we want a HAVING clause 17:32:33 <dajobe> move syntax stuff to editors 17:32:46 <dajobe> kasei: what we name it. ref to SQL 17:33:02 <dajobe> SteveH: don't see need for HAVING as we have FILTER 17:33:08 <dajobe> there are things you can't have in both 17:33:20 <dajobe> you can't put an agg function in a filter 17:33:37 <dajobe> could make them syntactically the same 17:34:00 <dajobe> axel: why do we have a list of constraints in HavingClause (grammar)? 17:34:11 <dajobe> .. the only obvious difference 17:34:32 <dajobe> SteveH: in theory you could ban agg functions in FILTER and not inside HAVING but this makes grammar very ugly 17:34:33 <AxelPolleres> 'HAVING' HavingCondition+ 17:34:41 <AxelPolleres> why's the +? 17:37:15 <dajobe> SteveH: in sql, it needs a different keyword because of the syntax of sql 17:37:23 <dajobe> discussing what's easy for users to understand 17:38:20 <dajobe> ... it's essentially a group filter 17:39:33 <dajobe> SELECT ?o WHERE { ?s ?p ?o } GROUP BY ?o FILTER ?x > 10 17:39:39 <dajobe> [my formulation] 17:39:54 <AxelPolleres> SteveH: ... the semantics of FILTER in the place of "HAVING" is the same as the normal FILTER... no need for a separate keyword 17:39:58 <dajobe> vs SELECT ?o WHERE { ?s ?p ?o } GROUP BY ?o HAVING ?x > 10 17:40:18 <AxelPolleres> steve and greg lean towards only having FILTER 17:40:20 <dajobe> oops, igore ?x and pretend I wrote ?o 17:40:42 <dajobe> pgearon: coming from sql, having is familiar 17:40:49 <AxelPolleres> axel tends to agree, unless other findings which really prove it different. 17:41:54 <bglimm> I also tend to HAVING because it is familiar from sql 17:42:38 <AxelPolleres> ...but we could just tell them HAVING is called FILTER in sparql 17:43:12 <AxelPolleres> ... should be further discussed, no decision should be made in the small group we have now. 17:43:45 <pgearon> HAVING will make it easier for people in the future when they move from SPARQL and try to learn SQL for the first time :-) 17:44:28 <AxelPolleres> dajobe: does every implementation call it FILTER 17:44:29 <AxelPolleres> ? 17:44:39 <dajobe> seems there aren't that many 17:46:37 <dajobe> more discussion of impl of this 17:46:46 <dajobe> arq and virtuso and others prob follow sql and use having 17:46:57 <AxelPolleres> steve point out that both HAVING and FILTER are the same operation in the algebra. 17:47:04 <dajobe> next issue 17:47:08 <dajobe> aggregrate details 17:47:13 <dajobe> http://www.w3.org/2009/sparql/track/issues/16 17:47:16 <dajobe> distinct and * 17:47:26 <dajobe> 35, 41, 50 17:47:40 <dajobe> 35 "Can aggregate functions take DISTINCT as an argument a la SELECT COUNT(DISTINCT ?X)?" 17:47:49 <dajobe> http://www.w3.org/2009/sparql/track/issues/35 17:48:50 <dajobe> trying to see if consensus in room 17:48:58 <pgearon> my implementation will allow for this, but I don't know about the general case 17:49:00 <dajobe> lee: allow distinct to all agg 17:49:08 <dajobe> lee: my impl allows distinct to all agg 17:49:59 <AxelPolleres> (topic is issue-35) 17:51:27 <dajobe> distinctness is applied before the rows are handed off to the agg functions 17:51:32 <dajobe> ^agg 17:52:05 <dajobe> makes sense for COUNT DISTINCT and SUM DISTINCT and probably others, including extension agg funcitons 17:52:39 <AxelPolleres> Note: we actually discussed ISSUE-41 in the context of ISSUE-11 already. 17:53:06 <dajobe> in sql the distinct applies to the variable not the function 17:53:50 <AxelPolleres> so would it then be COUNT DISTINCT(...) or COUNT (DISTINCT ... ) ? 17:53:53 <dajobe> kasei: but for some cases you'd want to optimize count distinct rather than mateiralises the distinct values 17:54:46 <LeeF> SELECT COUNT(DISTINCT ?x, ?y) 17:55:31 <AxelPolleres> THere seems to be again a reduncancy wrt. subqueries, since the bahaviour could be achieved with a DISTINCT subselect as well. 17:55:55 <dajobe> want to do distinct but not sure how it works with multipel arguments 17:55:59 <dajobe> all the builtin funcs have 1 arg 17:56:11 <dajobe> if it was allowed over 1 var, still could do it with subselects 17:56:47 <AxelPolleres> axel: if we don't have consensus, given the redundancy, I'd be happy enough to leave DISTINCT in aggregates out. 17:57:06 <dajobe> discussion of what sql allows 17:57:08 <AxelPolleres> ... unless someone claims it in. 17:59:20 <AxelPolleres> ... Lee does claim it in, it seems. 17:59:24 <LeeF> SELECT COUNT(DISTINCT ?x) COUNT(?y) { ?key :p1 ?x . OPTIONAL { ?key :p2 ?y } } GROUP BY ?key 18:00:57 <dajobe> count *: counts rows aka sparql solutions 18:01:01 <dajobe> count ?var counts values 18:01:08 <dajobe> dont think other functions can use/need * 18:01:16 <dajobe> comparing to sql 18:03:43 <dajobe> consensus in room on distinct with 1 arg 18:03:48 <dajobe> with agg funcs 18:08:11 <AxelPolleres> there is no way in the current grammar we have in FPWD to write something like COUNT ( ?x ?y) all aggregates are about 1 expression, aren't they? 18:08:24 <LeeF> ACTION: Lee to summarize strawman of how aggregates, DISTINCT, and * work (per Glitter's behavior) 18:08:24 <trackbot> Created ACTION-131 - Summarize strawman of how aggregates, DISTINCT, and * work (per Glitter's behavior) [on Lee Feigenbaum - due 2009-11-09]. 18:10:37 <AxelPolleres> lee: suggest that we have signatures for aggregates as for other functions. 18:12:29 <dajobe> curreng builting agg funcs have 1 arg 18:12:32 <dajobe> only count makes sense with * 18:12:40 <dajobe> and for sql that's a diff operation - couting rows, not values 18:12:48 <dajobe> so maybe should be a 5th builtin agg function 18:13:31 <LeeF> I'm attempting to track issues we discuss which seem to have consensus from F2F attendees but for which we're not resolving issues on this wiki page: http://www.w3.org/2009/sparql/wiki/F2F2_Issue_Discussions 18:15:42 <dajobe> SteveH and axel discuss count(*) 18:15:49 <dajobe> which apparently is wierd in SQL 18:17:03 <dajobe> seem to see that there is consensus that count* is special 18:17:17 <dajobe> and the only agg function that needs it, so don't need to allow it for extension agg functions 18:17:25 <dajobe> otherwise distinct is allowed for all agg functioons 18:17:30 <dajobe> built in and extension 18:17:36 <dajobe> they can all take multiple expression arguments 18:17:44 <AxelPolleres> count ?X { :bob a :Person OPTIONAL { :bob :mbox ?X } } is different �from count * { :bob a :Person OPTIONAL { :bob :mbox ?X } } 18:17:56 <AxelPolleres> on graph {:bob a :Person} 18:18:21 <AxelPolleres> ... that is indeed a bit weird, yes. 18:19:09 <dajobe> this was some of #35 which we think we have consensus, but not resolve it 18:19:12 <LeeF> http://www.w3.org/2009/sparql/wiki/F2F2_Issue_Discussions 18:22:07 <dajobe> the above doc is to capture the consenus at the f2f to bring to wider group 18:22:26 <dajobe> 41 ... http://www.w3.org/2009/sparql/track/issues/41 18:22:36 <dajobe> we've covered that 18:22:50 <dajobe> point to options for issue #11 18:24:38 <dajobe> 50 ... http://www.w3.org/2009/sparql/track/issues/50 18:26:42 <dajobe> that's so MEAN 18:27:34 <pgearon> I suggest following SQL on this one. If Excel uses "MEAN" then that's a good reason to use AVG, isn't it? 18:29:10 <LeeF> ISSUE-50: advice to editors is to keep it like SQL (AVG) 18:29:10 <trackbot> ISSUE-50 Should the average/arithmetic mean aggregate be called AVG, MEAN, both, or something else? notes added 18:29:15 <LeeF> trackbot, close ISSUE-50 18:29:15 <trackbot> ISSUE-50 Should the average/arithmetic mean aggregate be called AVG, MEAN, both, or something else? closed 18:30:05 <dajobe> # Mixed datatypes left 18:30:08 <dajobe> and "Syntax" 18:30:14 <dajobe> whether custom aggs should have a keyword 18:30:42 <dajobe> no issue to track this 18:30:45 <dajobe> discusing that now 18:30:53 <dajobe> want to allow people to define agg functions with uris 18:30:55 <dajobe> issue #15 18:31:00 <dajobe> http://www.w3.org/2009/sparql/track/issues/15 18:31:08 <dajobe> ... do we do this same was as extension functions 18:31:14 <dajobe> (lee) or introduce some keyword 18:31:32 <dajobe> e.g. ..(AGG foo:bar(DISTINCT args)) 18:31:41 <dajobe> where foo:bar is the uri of the extension funcs 18:32:18 <dajobe> discussing about whetehr need keyword from people in room 18:32:21 <dajobe> SteveH: doesn't carea 18:32:34 <dajobe> axel; useful for service description for defining agg funcs for signature of them 18:33:06 <dajobe> ... or maybe not for our service description. discussion of htat in room 18:33:52 <dajobe> dajobe: I would like keyword, they are so diff from functions 18:33:57 <dajobe> e.g. rules on pasing in vars and checking rules 18:34:58 <dajobe> the problem: is how you distinct custome aggregates from custom scalar functions and casts 18:35:12 <LeeF> SELECT ?foo ex:bar(?baz) 18:35:13 <dajobe> there are different checks for each of agg/funcs/casts 18:35:15 <AxelPolleres> question is how to distinguish custom aggregates from custom scalar functions/casts... 18:35:58 <pgearon> casts are limited to a certain set of URIs, aren't they? 18:36:12 <dajobe> pgearon: not for user datatypes? 18:36:16 <AxelPolleres> SELECT ?foo ex:bar{?baz} 18:36:43 <AxelPolleres> ... for aggregates... might raise ambiguities, not sure 18:38:19 <SteveH> SELECT ?foo AGG ex:bar (DISTINCT ?baz) 18:38:20 <SteveH> or 18:38:27 <SteveH> SELECT ?foo AGG(ex:bar, DISTINCT ?baz) 18:38:33 <LeeF> AGG(ex:bar(?x, ?y)) 18:38:37 <dajobe> AGG(ex:bar(DISTINCT ?bar ?blah)) 18:38:56 <dajobe> AGG ex:bar(DISTINCT ?bar ?blah) 18:42:01 <dajobe> e.g ex:bar[DISTINCT ?bar ?blah] 18:42:04 <dajobe> ^- my suggestion 18:42:18 <dajobe> or all agg funcs 18:42:22 <dajobe> COUNT[?var] etc. 18:42:30 <kasei> s/or/for/ 18:42:55 <dajobe> COUNT<?var> <- NO 18:43:31 <dajobe> choices 18:43:46 <dajobe> 1. bare function SELECT ex:bar(DISTINCT ?bar ?blah) 18:44:10 <dajobe> 2. keyworded SELECT AGG/AGGREGATE ex:bar(DISTINCT ?bar ?blah) 18:44:25 <dajobe> 3. add syntax to make extension functions look different SELECT ex:bar[DISTINCT ?bar ?blah] 18:44:45 <dajobe> ... and apply that to all builtin agg funcs/extension agg funcs 18:45:24 <dajobe> tangental discussion of not wanting QL to depend on service desc 18:45:37 <dajobe> .. especially as some impls won't have a service 18:46:00 <dajobe> the world of sparql functions is defined in the sparql ql spec 18:46:06 <dajobe> the service desc, describes that 18:46:13 <dajobe> with some pre-defined agg funcs 18:50:28 <dajobe> how common is this? steve wants it. lee: pretty common 18:51:33 <AxelPolleres> Option1: keyword for all aggregates 18:51:33 <AxelPolleres> Option2: keyword for external aggregates only 18:51:34 <AxelPolleres> Option3: no keyword 18:51:55 <AxelPolleres> .... let's leave it to the editors to pick one and then discuss further. 18:53:13 <AxelPolleres> Option4: [ ] 18:53:17 <dajobe> 15-20 min break 18:53:31 <Zakim> -pgearon #18:53:33 <Zakim> -TPAC_SPARQL 18:53:36 <Zakim> SW_SPARQL(TPAC)11:30AM has ended 18:53:38 <Zakim> Attendees were SteveH, kasei, leef, dajobe, cdsm, pgearon, bglimm, Suite_a, TPAC_SPARQL 19:00:25 <LukeWM> LukeWM has joined #sparql 19:03:21 <LukeWM> LukeWM has joined #sparql 19:03:47 <LukeWM> LukeWM has joined #sparql 19:15:16 <dajobe> we're still missing a couple of people here, maybe 5mins 19:15:48 <ted> ted has joined #sparql 19:16:08 <dajobe> we'll restart soon 19:16:16 <dajobe> and if we can get zakim to call us, that would be super 19:16:43 <dajobe> it didn't work last 2 times 19:17:13 <Zakim> SW_SPARQL(TPAC)11:30AM has now started 19:17:14 <Zakim> +Suite_a 19:17:38 <ted> ted has left #sparql 19:17:48 <LeeF> zakim, who's on the phone? 19:17:48 <Zakim> On the phone I see Suite_a 19:19:43 <AxelPolleres> AxelPolleres has joined #sparql 19:20:28 <Zakim> +bglimm 19:20:42 <bglimm> Ican call now from the UK 19:20:52 <bglimm> Zakim, mute me 19:20:52 <Zakim> bglimm should now be muted 19:22:04 <kasei> scribenick: kasei 19:22:49 <kasei> LeeF: I think any solution that has aggregate functions returning multiple results per group is horrible. 19:22:59 <kasei> SteveH: I agree. 19:23:22 <AxelPolleres> topic: mixed datatypes & aggregates 19:23:26 <kasei> LeeF summarizing the issue for observers. 19:23:49 <kasei> LeeF: Possibility - return a row per datatype. 19:23:59 <kasei> ... link somewhere on a summary of the issue. 19:24:24 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0250.html 19:25:09 <kasei> LeeF: Option 1 - (all in the context of MIN) impl can pick one of the datatypes and take MIN of those values and ignore everything else 19:25:47 <kasei> dajobe: some things will be discarded, some things will give you a numeric value? 19:26:04 <kasei> ... going to provide semantics for built-in functions. custom ones can do whatever they like. 19:26:07 <csma> csma has joined #sparql 19:26:31 <kasei> LeeF: addressing this for built-ins, especially for MIN and MAX 19:26:55 <kasei> SteveH: framework for aggregates should imply agg functions only return one value. 19:27:10 <kasei> dajobe: so important issue is determining how you decide which one value you return. 19:27:28 <kasei> SteveH: need to sort out cases with unbound values and type errors. 19:27:46 <kasei> LeeF: taking MIN of lots of values (ints, dates, unbound, ...) 19:28:09 <kasei> ... pick a values space for MIN based on first encountered datatype. ignore any other values that can't be compared with that value space. 19:28:52 <kasei> dajobe: can promote from int to decimal, e.g., if you encounter int first and then decimal. 19:29:25 <kasei> LeeF: yes. numerics would be ok, but ignore dates and strings. 19:29:36 <kasei> dajobe: unportable based on whatever you see first. 19:29:43 <LeeF> MIN(xsd:dateTime, ?x) 19:30:05 <AxelPolleres> is redundant w.r.t. MIN(xsd:dateTime(?x)) 19:30:09 <kasei> LeeF: for every value in list, if it has a safe cast to datatype, convert and use less than, otherwise ignore. 19:30:50 <kasei> Axel: should not behave differently than explicit cast. 19:31:20 <kasei> dajobe: subtle difference between type promotion and casting. 19:31:42 <kasei> Axel: that was option 2 19:32:49 <kasei> dajobe: could have min-date, min-numeric, min-string 19:33:01 <kasei> SteveH: could be based on ORDER BY sorting 19:33:07 <LeeF> http://www.w3.org/TR/rdf-sparql-query/#modOrderBy 19:33:23 <kasei> SteveH: only gives a partial ordering 19:34:31 <kasei> LeeF: doesn't help with mixed literals and datatypes 19:35:08 <kasei> LeeF: another option is simply an error if you have datatypes that aren't comparable. 19:35:19 <kasei> ... need to ask what happens if this error is encountered. 19:36:14 <kasei> ... could say its the same as ORDER BY and let implementations sort out any total orderings (same as ORDER BY now) 19:37:05 <iv_an_ru> Our experience shows that it's good to have a "quiet cast" that either casts to a desired datatype (if possible) or return NULL (if there's no way); where plain cast signals an error, "quiet cast" returns NULL. Good to compute at least something on RDF mess... 19:38:11 <pgearon> looks like I can't dial in for a couple of hours. I may be on later, but if not, I'll be back tomorrow morning. Have fun 19:39:24 <AxelPolleres> reads ugly, but, if we had IF, we could... MIN(IF(xs:int(?X)>0;xs:int(?X);0)) keeps it all at the user to catch errors, so that would make Option 4 work 19:39:37 <kasei> LeeF: my preference for MIN/MAX is same as ORDER BY, with some bits being implementation defined. 19:39:48 <kasei> dajobe: for SUM you can delegate to + 19:39:56 <kasei> ... AVG would be also be + 19:40:06 <kasei> SteveH: mode/median would be tricky, but might not have those 19:40:54 <kasei> LeeF: anyone not happy with that? 19:41:18 <bglimm> Zakim, unmute me 19:41:18 <Zakim> bglimm should no longer be muted 19:43:25 <kasei> LeeF: what happens when a type error bubbles up into the project level? 19:44:38 <kasei> SteveH: if you don't have a soft cast (per iv_an_ru) you have to filter at a lower level 19:45:56 <kasei> LeeF: three obvious answers 19:46:01 <kasei> ... the whoel query is an error 19:46:05 <kasei> ... treated as an unbound 19:46:16 <AxelPolleres> Options on error: 19:46:19 <kasei> ... invent some sort of type error value 19:46:41 <kasei> dajobe: "FAIL"^^xsd:typeError 19:46:59 <kasei> SteveH: collapsing to unbound is most sensible 19:47:19 <kasei> LeeF: one more option, "fail the row" 19:47:20 <iv_an_ru> "OMG"^^xsd:typeError ? 19:47:49 <kasei> dajobe: could choose between type errors and null. 19:47:54 <LeeF> iv_an_ru, :) 19:48:21 <kasei> LeeF: concern with coalesce - will it treat unbound and type errors the same? 19:48:38 <kasei> SteveH: point of coalesce is that you get back a thing you can work with. 19:49:33 <kasei> Axel: what's wrong with treating it as unbound? 19:49:47 <kasei> LeeF: lose ability to distinguish the two. 19:50:33 <kasei> ... when I implemented IF, I have three branches for true, false, and error. 19:50:50 <kasei> ... could add an ISERROR() akin to BOUND() 19:50:54 <iv_an_ru> unbound(X), smells_bad(X), can_eat(X)... 19:51:16 <kasei> SteveH: discarding the row seems better than failing the whole query. 19:51:34 <iv_an_ru> kasei, +1 19:51:34 <kasei> LeeF: does anyone think type errors should fail the whole query? 19:52:00 <bglimm> I would like if the user can find ou whether some values were discarded 19:52:31 <bglimm> or explicitly gives permission to discard rows 19:54:32 <kasei> dajobe: could use coalesce with a sentinel value 19:54:38 <iv_an_ru> Fortunately, ODBC does not give me a way to transfer a value of type "error", so I don't have to worry. I can't make it metter than now, despite of what we'll write in the document. 19:55:02 <iv_an_ru> s/metter/better/ 19:55:28 <kasei> dajobe: SELECT FAILED(...) ? 19:55:51 <dajobe> each suggestion I've invented seems worse than the previous idea 19:56:22 <kasei> SteveH: what do we lose if we collapse to unbound values? 19:56:44 <kasei> LeeF: could have custom functions that return unbound. 19:58:44 <kasei> SteveH: can we agree to have ISERROR and COALESCE? 19:58:54 <kasei> dajobe: isn't it only useful with IF? 20:00:40 <kasei> SteveH: COALESCE takes any number of arguments, returning the first that's not unbound and not a type error. 20:01:08 <kasei> LeeF: I've implemented COALESCE and IF. Treats ubound and type errors as the same thing. 20:01:36 <AxelPolleres> the issue about bound() behaviour on error, didn't arise so far, because bound() could only take variables which - prior to projectexpressions - couldn't ever be errors... 20:01:58 <kasei> dajobe: this is the mechanism to turn the dropping of rows into using all rows with a sentinel value. 20:02:53 <dajobe> SELECT COALESCE(?x) returns rows 20:03:05 <dajobe> SELECT ?x discards rows with type errors 20:03:12 <SteveH> SELECT COALESCE(?x) AS ?y 20:03:17 <dajobe> yeah what SteveH said 20:03:19 <SteveH> ?y will be unbound if ?x is a type error 20:04:10 <dajobe> SELECT COALESCE(SUM(?x)) AS ?y 20:04:18 <dajobe> to handle type error rows 20:04:20 <dajobe> hmm! 20:05:36 <SteveH> COALESCE() -> unbound, COALESCE(type error, ...) -> COALESCE(...), COALESCE(unbound, ...) -> COALESCE(...), COALESCE(val, ...) -> val 20:05:54 <LeeF> SUM(COALESCE(xsd:decimal(?x), 0)) 20:07:22 <kasei> SteveH: can you use a scalar function as an argument to an aggregate function? 20:07:46 <SteveH> SUM(?x + ?y) 20:08:17 <LeeF> SUM(?x, ?y) 20:08:20 <SteveH> implies that + takes either a pair of scalars and returns a scalar, or pair of vectors and returns a pair of vectors 20:08:32 <dajobe> SUM(?x * ?x) 20:08:52 <dajobe> SUM(COALESCE(?x * ?x, 0)) 20:11:02 <SteveH> SELECT MIN(?val + 3) 20:11:02 <SteveH> WHERE { 20:11:02 <SteveH> ?x :val ?val 20:11:02 <SteveH> } GROUP BY ?x 20:15:04 <SteveH> question is, are "aggregates" functions or operators that look like functions 20:15:06 <kasei> Axel: summarizing - errors drop rows 20:15:51 <kasei> ... supporting coalesce would be a solution to handling type errors. 20:16:20 <kasei> dajobe: don't like the naming. 20:16:38 <kasei> LeeF: does anybody not want COALESCE? 20:17:31 <kasei> SteveH: should do what people expect it to do, despite error vs. typing issues different than SQL. 20:18:11 <kasei> Axel: COALESCE would handle errors and treat them the same as unbound. 20:18:18 <AxelPolleres> our coalesce would convert errors to nulls, ok, got it. 20:19:44 <kasei> SteveH: can we determine if aggregate functions take a singel value or a set? 20:20:47 <iv_an_ru> BTW there's a known SQL analog to "errors drop rows", namely "best effort union". When a middleware queries multiple remote parties to form longest possible union and some of remotes may be down, BEST EFFORT UNION steps over dead corps and continue to run. 20:21:38 <kasei> SteveH: in MIN(?val + 3), is ?val a value or a set? 20:21:42 <AndyS> AndyS has joined #sparql 20:22:09 <kasei> LeeF: semantics aren't in + dealing with sets/vectors, it's in the application of MIN and + in the context of aggregation. 20:22:56 <kasei> dajobe is diagraming the two interpretations. 20:23:05 <SteveH> hi AndyS 20:24:05 <LeeF> RRSAgent, make logs public 20:24:10 <LeeF> RRSAgent, pointer? 20:24:10 <RRSAgent> See http://www.w3.org/2009/11/02-sparql-irc#T20-24-10 20:24:20 <LeeF> FYI, AndyS - also see http://www.w3.org/2009/sparql/wiki/F2F2_Issue_Discussions 20:24:23 <LeeF> if you want :) 20:25:33 <kasei> LeeF: to support expressions in aggregates would involve pass by reference for the expression. 20:25:53 <kasei> SteveH: aggregate operation would take as arguments and expression and a solution set. 20:26:32 <kasei> Axel: existing algebra for aggregates take multiset as input. 20:26:43 <kasei> SteveH: would need to change that to also take an expression. 20:27:57 <kasei> Axel: multiset vs. sequence in aggregate operations is an issue. 20:28:03 <kasei> ... multisets don't have an order. 20:28:29 <kasei> SteveH: lots of things in the current algebra is wrong. 20:29:42 <kasei> LeeF: there's no ordering for an aggregate operation. ordering happens after that. 20:30:07 <kasei> ... e.g. GROUP-CONCAT doesn't have any deterministic ordering. 20:30:26 <kasei> ... multisets, not sequences, are used for aggregates. 20:31:10 <kasei> SteveH: think we're agreed that aggregate functions take a solution set and a pass by reference expression. 20:31:27 <SteveH> implication is that aggregate functions take a pass-by-reference expression and a solution set (implied) as arguments are return a scalar 20:31:32 <SteveH> what kasei said 20:32:28 <kasei> LeeF: do we allow expressions in aggregates, then? 20:32:49 <bglimm> ZAkim, mute me 20:32:49 <Zakim> bglimm should now be muted 20:33:32 <kasei> ... seems useful. 20:33:53 <kasei> SteveH: almost essential in arguments to agg functions, possible not needed in GROUP BY. 20:34:04 <kasei> dajobe: current syntax in 1.1 has this already. 20:34:44 <kasei> SteveH: algebra needs work to properly explain this. 20:35:23 <LeeF> ACTION: Steve to make sure algebra has some position on what aggregate functions are & do (w.r.t. expressions by reference) 20:35:23 <trackbot> Created ACTION-132 - Make sure algebra has some position on what aggregate functions are & do (w.r.t. expressions by reference) [on Steve Harris - due 2009-11-09]. 20:39:54 <kasei> topic: Project Expressions syntax 20:40:36 <kasei> SteveH: not convinced all expressions need an alias 20:40:51 <kasei> ... would just name them by the expression 20:40:59 <kasei> dajobe: need to change result formats, then. 20:44:02 <dajobe> and all the software apis 20:44:09 <dajobe> and define a canonical form for serializing sparql expressions 20:45:22 <kasei> LeeF: syntax options 20:46:16 <LeeF> (expr AS ?alias) 20:46:32 <LeeF> (expr) AS ?alias 20:46:52 <LeeF> , expr AS ?alias , 20:47:35 <kasei> dajobe: don't care as long as it's not ambiguous. 20:47:56 <kasei> SteveH: not mutually exclusive. 20:48:13 <kasei> LeeF: without parens, commas are needed. 20:48:48 <kasei> dajobe: would prefer parens to aid lex/yacc 20:48:58 <AxelPolleres> PrimaryExpression 'AS' Var ... should work, or what do I miss? 20:49:34 <AxelPolleres> .... with or without commas?!? 20:50:16 <AxelPolleres> because the grammar becomes contextual? does it? 20:50:17 <kasei> LeeF: easiest to require brackets and alias all the time 20:50:19 <SteveH> SELECT ?x+?y AS ?plus WHERE { ... } 20:50:44 <dajobe> SELECT ?x +?y AS ?plus ... 20:51:38 <dajobe> SELECT ?x , +?y AS ?plus ... 20:51:44 <dajobe> last 2 are the same and project 2 vars 20:52:14 <AxelPolleres> so BrackettedExpression 'AS' Var 20:53:49 <kasei> dajobe: using expressions where variables used to be means we'll be using lots of brackets anyway 20:55:01 <AxelPolleres> '(' Expression AS Var ')' vs. BrackettedExpression 'AS' Var 20:55:54 <dajobe> I think "SELECT ?x?y?z" is probably legal today 20:55:59 <kasei> SteveH: Can live with (expr AS ?alias) 20:57:10 <dajobe> SELECT FOO ?x expr1 ?y ... 20:57:43 <kasei> dajobe: if the syntax was reversed ambiguity would be gone. 20:57:46 <dajobe> SELECT FOO ?plus ?x+?y 20:57:50 <AxelPolleres> s/FOO/LET :-) 20:58:24 <dajobe> no, this is a mess 20:58:27 <kasei> kasei: still the same problem with whitespace before the '+' 20:58:46 <dajobe> SELECT FOO(?plus, ?x+y) 20:59:01 <SteveH> RENAME(foo, ?x+?y) 20:59:17 <dajobe> SELECT (?plus as ?x+?y) 20:59:27 <dajobe> or SELECT ?plus as (?x+?y) 21:00:25 <SteveH> break for lunch... 21:00:29 <bglimm> Zakim, unmute me 21:00:29 <Zakim> bglimm should no longer be muted 21:00:38 <LeeF> Lunch. 21:00:39 <Zakim> -bglimm 21:38:32 <DanC> DanC has joined #sparql 21:49:13 <AxelPolleres> AxelPolleres has joined #sparql 21:50:36 <SteveH_> SteveH_ has joined #sparql 21:53:13 <csma> csma has joined #sparql 21:57:04 <LeeF> LeeF has joined #sparql 21:57:21 <LeeF> zakim, who's on the phone? 21:57:21 <Zakim> On the phone I see Suite_a 21:57:59 <LukeWM> LukeWM has joined #sparql 21:58:51 <dajobe> dajobe has joined #sparql 22:03:11 <AxelPolleres> without comma: 22:03:12 <AxelPolleres> Option1: ((BrackettedExpression 'AS')? Var)+ 22:03:12 <AxelPolleres> Option2: Var || ('('Experession 'AS' Var ')')+ 22:03:12 <AxelPolleres> with comma: 22:03:12 <AxelPolleres> Option3: projection := BrackettedExpression 'AS')? Var | projection ',' projection 22:03:14 <AxelPolleres> 22:04:32 <AxelPolleres> Option 3 means alternatively having the normal Varlist, where no project expressions are present. 22:06:26 <AxelPolleres> ... projection := (Expression 'AS')? Var | projection ',' projection 22:06:39 <AxelPolleres> (that was the corrected version of Option3) 22:09:37 <LeeF> scribenick: LeeF 22:15:24 <LeeF> <discussion of relationship between issue-5 and the exists/not exists filter functions currently in the sparql-1.1 WF) 22:15:27 <LeeF> s/WF/WD 22:15:39 <LeeF> SteveH_: don't like ASK inside FILTERs (or NOT EXISTS inside FILTERs) 22:16:30 <LeeF> AxelPolleres: What about the case where you wanted to combine other conditions with the ASK ? 22:16:40 <LeeF> SteveH_: Seems weird to have ASK and not other subqueries in the FILTER 22:18:19 <AxelPolleres> discussion is also tapping on issue-6 ... 22:18:45 <LeeF> LeeF: I'd probably do without any subqueries in FILTERs 22:20:22 <LeeF> AxelPolleres: select subqueries in filters are probably redundant with subselects, but it might be easier to write some things tha tway 22:20:29 <LeeF> ... if there was an IN operator 22:22:07 <DanC> DanC has joined #sparql 22:22:18 <LeeF> kasei: motivation for having not exists in FILTER was to be able to easily combine it with other conditions (w/o duplicating it across UNIONs, etc.) 22:24:01 <LeeF> kasei: I have EXISTS and NOT EXISTS in both graph patterns and filters and it doesn't seem too complicated 22:24:15 <LeeF> SteveH_: I can't build an optimizing version of NOT EXISTS in FILTER 22:26:33 <LeeF> SteveH_: algebraic style negation is expressively different from filter style 22:26:42 <LeeF> ... but filter style is same expressivity as actually being a FILTER 22:29:42 <LeeF> AxelPolleres: subqueries within FILTERs - is there any need? 22:29:47 <LeeF> ... 2 possible needs 22:29:54 <LeeF> ... 1) EXISTS (boolean subqueries in FILTERs) 22:30:10 <LeeF> ... 2) 1-variable SELECTs tied to one value usable in comparison expressions or potential IN expressions 22:31:02 <LeeF> dajobe: would add another type (array of values), which would need to be encounted for everywhere 22:31:43 <AxelPolleres_> AxelPolleres_ has joined #sparql 22:31:56 <SteveH_> FILTER( EXISTS { ?x :foo :y } ) 22:32:14 <SteveH_> FILTER( EXISTS { ?x :foo :y . FILTER( ?y = 3) } ) 22:33:34 <LeeF> kasei: is the distinction here just a syntax issue? 22:34:48 <LeeF> AxelPolleres: who wants FILTER EXISTS ? 22:39:06 <LeeF> LeeF: Why don't we report back a general feeling from today that we'd like to avoid this complexity if possible, and ask for any advocates to speak up? 22:39:42 <LeeF> AxelPolleres: boolean subqueries in FILTERs and SELECT subqueries in FILTERs should be questioned 22:39:51 <LeeF> kasei: SELECT in FILTER doesn't make sense without extra operators 22:41:33 <LeeF> subtopic: CONSTRUCT queries in FROM [NAMED] clause 22:41:55 <LeeF> SteveH_: is there any extra capabilities here? 22:42:18 <LeeF> kasei: consider several files to load and map the vocabularies into your own vocabulary 22:44:09 <AxelPolleres> http://www.polleres.net/publications/poll-etal-2007.pdf my example is on p.6 22:44:44 <dajobe> CONSTRUCT { ?a knows ?b . ?a foaf:name ?aname . ?b foaf:name ?bname . } 22:44:45 <dajobe> FROM { CONSTRUCT { _:auth foaf:name ?n . ?p aux:hasAuthor _:auth . } 22:44:45 <dajobe> FROM <g> WHERE { ?p dc:creator ?n . } } 22:44:45 <dajobe> WHERE { ?p aux:hasAuthor ?a . ?a foaf:name ?aname . 22:44:45 <dajobe> ?p aux:hasAuthor ?b . ?b foaf:name ?bname . FILTER ( ?a != ?b ) } 22:44:55 <DanC> DanC has joined #sparql 22:48:50 <dajobe> discussion of above query from page6 of paper PDF above 22:49:00 <dajobe> axel: seems necessary for social network like queries 22:51:00 <dajobe> SteveH_: thinks this can be done with sub-queries and some work 22:54:24 <LeeF> ACTION: Axel to followup with Chilleans re: not including sub-constructs in FROM clauses 22:54:24 <trackbot> Created ACTION-133 - Followup with Chilleans re: not including sub-constructs in FROM clauses [on Axel Polleres - due 2009-11-09]. 22:56:56 <LeeF> discussion that Axel seems to be the main - perhaps sole - proponent of sub-constructs in FROM clauses in the WG 23:03:41 <AxelPolleres> Lee: Would " SELECT ( _:b1 AS ?blank) ... " solve Axel's use case? 23:03:44 <AxelPolleres> Axel: yes. 23:04:09 <AxelPolleres> ... if it has the same semantics as blanknodes in CONSTRUCT 23:04:27 <LeeF> ACTION: Steve and Andy to figure out what happens with SELECT ( _:b1 AS ?blank) 23:04:27 <trackbot> Created ACTION-134 - And Andy to figure out what happens with SELECT ( _:b1 AS ?blank) [on Steve Harris - due 2009-11-09]. 23:04:34 <AxelPolleres> Lee: you could also write SELECT ( [] AS ?�blank) ... " of course 23:07:33 <dajobe> SELECT ( ?var = _:B1 AS ?foo ) 23:09:00 <LeeF> s/SELECT ( ?var = _:B1 AS ?foo )/YOU NEVER SAW THIS 23:09:08 <dajobe> hey! that's legal 23:09:16 <LeeF> RRSAgent, this meeting spans midnight 23:14:05 <SteveH_> ACTION-134: this should probably do the same thing as CONSTRUCT, i.e. mint new bnodes for each solution 23:14:05 <trackbot> ACTION-134 And Andy to figure out what happens with SELECT ( _:b1 AS ?blank) notes added 23:16:32 <LeeF> <discussion that issue-10 is obviated by EXISTS text in current WD> 23:18:27 <LeeF> ISSUE-10: obviated by EXISTS, F2F2 noted this is not too helpful anyway 23:18:27 <trackbot> ISSUE-10 ASK queries in graph patterns? notes added 23:18:31 <LeeF> trackbot, close ISSUE-10 23:18:31 <trackbot> ISSUE-10 ASK queries in graph patterns? closed 23:23:52 <AxelPolleres> topic: issue-39 23:25:10 <dajobe> SELECT ?a (?a AS ?b) (?c as ?b) 23:25:25 <dajobe> legal or not, vote now! 23:26:41 <dajobe> discussion of project variables in these kind of cases, esp in subqueries 23:26:54 <dajobe> { SELECT (?x + ?y AS ?sum) (?sum * ?qty as ?price) } 23:27:03 <dajobe> ^- illegal in lee and steve's engine 23:27:18 <dajobe> ... ?sum and ?price only appear in parent scope - the oute r{} 23:30:40 <LeeF> ...also illegal / doesn't work in kasei's impl 23:33:48 <LeeF> LeeF: open question of whether doing this (same variable in query and as an alias) is an error or not 23:34:13 <LeeF> ...alternative would be that it's just a separate variable universe #23:38:55 <Zakim> -Suite_a 23:38:56 <Zakim> SW_SPARQL(TPAC)11:30AM has ended 23:38:56 <Zakim> Attendees were Suite_a, bglimm 23:39:30 <csma> csma has joined #sparql 00:15:10 <Zakim> Zakim has left #sparql 00:15:52 <AxelPolleres> AxelPolleres has joined #sparql 00:15:58 <AxelPolleres> discussing with HCLS. 00:16:12 <AxelPolleres> mention of property paths. 00:17:05 <AxelPolleres> discuss that we need to take care of cycles, need for path lengths, how that relates to subsumption reasoning, etc. 00:17:31 <AxelPolleres> eric now explaining basic federation 00:20:07 <AxelPolleres> update, service description, graph management protocol, entailment 00:25:46 <LeeF> LeeF has joined #sparql 00:36:33 <AxelPolleres> HCLS asks for something like functional syntax, Lee mentions its being discussed at the moment, mayb end up as a note. 00:40:22 <AxelPolleres> AxelPolleres has joined #sparql 01:06:07 <AxelPolleres> AxelPolleres has joined #sparql 01:27:41 <AxelPolleres> AxelPolleres has joined #sparql 03:50:11 <AxelPolleres> AxelPolleres has joined #sparql 04:04:49 <LeeF> LeeF has joined #sparql # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000727