Chatlog 2009-11-02

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