13:54:34 <RRSAgent> RRSAgent has joined #sparql
13:54:34 <RRSAgent> logging to http://www.w3.org/2010/08/31-sparql-irc
13:54:36 <trackbot> RRSAgent, make logs world
13:54:36 <Zakim> Zakim has joined #sparql
13:54:38 <trackbot> Zakim, this will be 77277
13:54:38 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 6 minutes
13:54:39 <trackbot> Meeting: SPARQL Working Group Teleconference
13:54:39 <trackbot> Date: 31 August 2010
13:54:41 <LeeF> zakim, this will be SPARQL
13:54:41 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 6 minutes
13:54:45 <LeeF> Chair: LeeF
13:54:49 <LeeF> Scribenick: sandro
13:55:01 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-08-31
13:57:08 <NicoM> NicoM has joined #sparql
13:57:38 <LeeF> sandro, are you available to scribe today?
13:59:01 <Zakim> SW_(SPARQL)10:00AM has now started
13:59:09 <Zakim> +NicoM
13:59:16 <NickH> NickH has joined #sparql
13:59:32 <Zakim> +Lee_Feigenbaum
13:59:45 <NickH> booooo
13:59:53 <NickH> I am too late for the UK phone number :(
13:59:55 <Zakim> +kasei
14:00:00 <ivan> zakim, dial ivan-voip
14:00:00 <Zakim> ok, ivan; the call is being made
14:00:04 <Zakim> +Ivan
14:00:27 <Zakim> +??P22
14:00:35 <AndyS> zakim, ??P22 is me
14:00:35 <Zakim> +AndyS; got it
14:00:44 <MattPerry> MattPerry has joined #sparql
14:00:44 <AndyS> zakim, who is on the phone
14:00:44 <Zakim> I don't understand 'who is on the phone', AndyS
14:00:51 <AndyS> zakim, who is on the phone?
14:00:51 <Zakim> On the phone I see NicoM, Lee_Feigenbaum, kasei, Ivan, AndyS
14:02:20 <LeeF> zakim, Lee_Feigenbaum is me
14:02:20 <Zakim> +LeeF; got it
14:02:58 <Zakim> +Sandro
14:03:35 <Zakim> +[IPcaller]
14:03:44 <SteveH_> Zakim, [IPcaller] is me
14:03:44 <Zakim> +SteveH_; got it
14:03:45 <sandro> sandro has changed the topic to: Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-08-31
14:03:54 <LeeF> Scribenick: Sandro
14:03:59 <SteveH_> hi, sorry, trouble connecting
14:04:03 <bglimm> Sorry, can't find a telephone line as usual
14:04:19 <Zakim> +bglimm
14:04:26 <Zakim> +MattPerry
14:04:31 <LeeF> zakim, who's on the phone?
14:04:31 <Zakim> On the phone I see NicoM, LeeF, kasei, Ivan, AndyS, Sandro, SteveH_, bglimm, MattPerry
14:04:32 <bglimm> France has telephone lines...
14:04:37 <SteveH_> does zakim have the ability to call voip addresses in/out?
14:04:40 <LeeF> zakim, who's speaking?
14:04:41 <Souri> Souri has joined #sparql
14:04:50 <Zakim> LeeF, listening for 10 seconds I heard sound from the following: AndyS (49%)
14:04:56 <AndyS> ack
14:05:04 <SteveH_> AndyS, on time doesn't help :(
14:05:06 <Zakim> +Souri
14:05:14 <LeeF> topic: Admin
14:05:17 <AndyS> Should be better?
14:05:18 <Zakim> +[IPcaller]
14:05:18 <bglimm> Ivan, Sandro, will there be more UK phone numbers any time soon?  
14:05:26 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-08-24
14:05:31 <AlexPassant> Zakim, IPcaller is me
14:05:32 <Zakim> +AlexPassant; got it
14:05:34 <sandro> bglimm, I know there are folks working on it.  I don't know the prognosis.
14:05:42 <bglimm> Zakim, mute me
14:05:42 <Zakim> sorry, bglimm, I do not know which phone connection belongs to me
14:05:48 <Zakim> +??P35
14:05:56 <bglimm> Zakim, I hate you sometimes!
14:05:56 <Zakim> I don't understand 'I hate you sometimes!', bglimm
14:06:08 <bglimm> Zakim, who is on the phone?
14:06:08 <Zakim> On the phone I see NicoM, LeeF, kasei, Ivan, AndyS, Sandro, SteveH_, bglimm, MattPerry, Souri, AlexPassant, ??P35
14:06:10 <NickH> Zakim, ??P35 is me
14:06:11 <Zakim> +NickH; got it
14:06:11 <sandro> bglimm, my guess is the next step may actually be direct VOIP into Zakim.  
14:06:29 <bglimm> How can I do that?
14:06:41 <AndyS> zakim, mute me
14:06:41 <Zakim> AndyS should now be muted
14:07:00 <AndyS> zakim, unmute me
14:07:00 <Zakim> AndyS should no longer be muted
14:07:08 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-08-24
14:07:30 <LeeF> Next regular meeting: 2010-09-07 @ 15:00 UK / 10:00 EDT (scribe: Axel Polleres ) 
14:07:38 <AndyS> Regrets for next week.
14:07:46 <LeeF> Regrets: AxelPolleres, Olivier
14:07:51 <LeeF> Regrets next week: Andy, Ivan
14:07:53 <SteveH_> Regrets for the two weeks following that, if that helps
14:08:15 <Zakim> +pgearon
14:08:39 <LeeF> overview document - http://www.w3.org/2009/sparql/wiki/Overview-Document
14:09:18 <sandro> LeeF: Axel and I will take the lead on the overview, but it's a wiki -- please go ahead and put some time into it if you feel like it.
14:09:57 <sandro> LeeF: My intention is to credit it to the entire wg, not me and Axel.
14:10:26 <AxelPolleres> My main question would be if it is ok/wanted to go with a simple example/scenario or whether to leave out examples, crediting whole WG is a good idea!  
14:10:33 <LeeF> topic: Projecting expressions used for grouping
14:11:50 <sandro> lee: this particular question never had an issue
14:12:02 <sandro> lee: if you group by expression, can you project out that expression?
14:12:28 <sandro> lee: if you group by x+y can you then project out y+x?    can you project out y+x+0?    etc.
14:12:49 <sandro> lee: by the time this rule is in effect, the expression has been parsed, etc.  
14:13:02 <sandro> lee: issue-11 said you can only project out group keys
14:13:10 <sandro> lee: issue-?? said ??
14:13:27 <sandro> lee: mailing list seemed to reach consensus 
14:13:39 <AxelPolleres> only allowing variables (plus allowing aliasing in the GROUP BY expression seems a  reasonable syntactic sugar for a subselect. 
14:13:53 <LeeF> Axel's email is here: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0300.html
14:14:30 <LeeF> * Expresssions can be used in GROUP BY
14:14:42 <LeeF> * Expressions in GROUP BY can be aliases to a variable using 'AS'
14:15:09 <LeeF> * All variables in the projection that are not part of an aggregate, must appear either on their own or as an alias in the GROUP BY
14:15:28 <LeeF> GROUP BY ?x   --allows-->   SELECT ?x (SUM(?y) ...)
14:15:48 <LeeF> GROUP BY (?x + ?y AS ?sum)   --allows-->   SELECT ?sum ...
14:16:17 <ivan> q+
14:16:24 <SteveH_> q+
14:16:30 <ivan> q-
14:16:39 <AxelPolleres> note that the latter may be viewed as syntactiv shortcut for a subselect
14:16:45 <ivan> ack SteveH_ 
14:16:47 <ivan> q+
14:17:22 <AxelPolleres> depending on how we proceed on the assignment issue, allowing AS in GROUP By will be expressible then in three different ways:
14:17:42 <AndyS> equiv?: GROUP BY and AS introduces a new variable to the group key :: can only project group key variables.
14:17:46 <sandro> andy: order of applying steps is currently speculative
14:17:48 <AxelPolleres> a) by subselect, b) by assignment c) by group by with alias.
14:17:54 <LeeF> s/andy/steveh
14:17:55 <AndyS> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlSolutions
14:18:01 <LeeF> ack ivan
14:18:06 <AxelPolleres> ... not a big problem, but just that we're all aware
14:18:29 <SteveH_> AndyS, is that new?
14:18:34 <sandro> ivan: what is ?y in your first example?
14:18:44 <AndyS> SteveH_, no
14:18:47 <sandro> lee: just to show you can always other variables inside aggregates like SUM
14:18:56 <SteveH_> AndyS, ok, I just missed it then, sorry!
14:19:12 <sandro> ivan: open issue on assignment stuff ("let"); doesn't that make it possible to simplify GROUP BY ?
14:19:49 <sandro> lee: I haven't thought about that.    But maybe, yes.
14:19:50 <AndyS> Corrected recently: http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#convertSolMod has always been correct subject to you agreeing - this is my assumption pending aggregate text (summary of a prev discussion IIRC).
14:20:02 <AndyS> q+
14:20:26 <sandro> ivan: I'm just raising this as a possible idea for simplifying things, so let's not close this before that.
14:20:33 <LeeF> ack AndyS
14:20:36 <pgearon> +q
14:21:07 <sandro> AndyS: I think Ivan's right, but you need the machinery to make SELECT expressions work, more than assignement, per se.
14:21:18 <Zakim> +[Garlik]
14:21:24 <Zakim> -SteveH_
14:21:35 <SteveH_> Zakim, [Garlik] is temporarily me
14:21:35 <Zakim> +SteveH_; got it
14:21:35 <sandro> lee: Ivan is saying we only allow group by variable, but then you have assignment....
14:21:46 <LeeF> SELECT ?sum ... WHERE { ... ?x ?y ... BIND ( ?sum := ?x + ?y ) } GROUP BY ?sunm
14:22:24 <LeeF> ack pgearon
14:22:35 <pgearon> q-
14:23:38 <SteveH_> they seems quite closely related, I agree with ivan
14:24:00 <SteveH_> GROUP BY xsd:integer(?x) is what I expect to see most
14:24:08 <sandro> AndyS: I think the most common use of expressions is for group-by, not for project.   so that suggests allowing group-by expression.
14:24:15 <ivan> q+
14:24:21 <LeeF> ack ivan
14:24:24 <sandro> AndyS: (just my intuition)
14:24:47 <sandro> ivan: In SteveH_'s example, what's the variable I can use in SELECT?
14:24:58 <SteveH_> GROUP BY (xsd:integer(?x) AS ?xint)
14:25:16 <sandro> lee: in that example you cannot project it out; if you want to, you'd have to include an alias, as in: GROUP BY (xsd:integer(?x) AS ?xint)
14:25:51 <SteveH_> q+
14:25:55 <LeeF> ack SteveH_
14:25:56 <sandro> ivan: From the user's point of view, I want the spec as simple as possible.    So if we have a LET, then it seems like we have two different ways to do the same thing.
14:26:22 <sandro> SteveH_, LET or BIND is already syntactic sugar for sub-select with projection, so I don't think this changes that.
14:26:43 <AxelPolleres> both true.
14:27:08 <sandro> SteveH_, LET gives us a second syntax, and that second syntax would be available in both places.
14:27:17 <sandro> ivan: okay
14:27:28 <AxelPolleres> that's why at least I would like to have a consistent syntax for assignment, relying on AS 
14:28:04 <sandro> lee: Is the alias created inside the query pattern, or can you just create it in the GROUP BY?
14:28:05 <AxelPolleres> not having ":=" in one and "AS" in another shortcut for subselect with Project expr.
14:28:08 <AndyS> Or rely on := everywhere
14:28:21 <AxelPolleres> also ok for me, if no grammar issues, andy
14:28:27 <SteveH_> or BIND (?x+?y AS ?xpy)
14:28:33 <sandro> Lee: shall we decide this before deciding about LET ?
14:28:58 <LeeF> question to the group: Do you want to wait until we decide about LET to decide about allowing aliased expressions in GROUP BY?
14:29:05 <SteveH_> yes
14:29:08 <ivan> yes
14:29:16 <AndyS> no
14:29:23 <AxelPolleres> 0
14:29:33 <bglimm> hm, undecided, tend to yes
14:29:46 <AndyS> to be clear - we can decide the principle now - details later.
14:29:53 <sandro> 0
14:29:57 <AndyS> happy to delay
14:30:09 <pgearon> yes to delay
14:30:29 <sandro> lee: conclusion: delay it.    but let's assert we have consensus on the principal
14:31:47 <Souri> we need to ensure that aliases in GROUP BY and aliases in SELECT do not conflict on alias names
14:31:57 <LeeF> PROPOSED: query results can be grouped by expressions, and those expressions can be aliased to a variable which can then be projected -- the mechanism for defining these aliases remains to be determined 
14:32:44 <AndyS> souri, yes - current text (SELECT expressions) should already cover that
14:33:04 <ivan> +1
14:33:07 <AndyS> seconded
14:33:15 <sandro> +1
14:33:17 <NicoM> +1
14:33:18 <AlexPassant> +1
14:33:19 <bglimm> +1
14:33:21 <MattPerry> +1
14:33:22 <pgearon> +1
14:34:01 <sandro> lee: If you have assignment, you can use it for the grouping.   The syntax isn't necessarily GROUP BY ?x+?y
14:34:01 <LeeF> PROPOSED: query results can be grouped by expressions, and those expressions can be aliased to a variable which can then be projected -- the mechanism & syntax for defining these aliases remains to be determined 
14:34:12 <SteveH_> +1
14:34:18 <Souri> +1
14:34:21 <MattPerry> +1
14:34:24 <LeeF> RESOLVED: query results can be grouped by expressions, and those expressions can be aliased to a variable which can then be projected -- the mechanism & syntax for defining these aliases remains to be determined 
14:34:53 <LeeF> ACTION: Lee to revisit the mechanism for aliasing group key expressions after the group has resolved the assignment issue
14:34:54 <trackbot> Created ACTION-303 - Revisit the mechanism for aliasing group key expressions after the group has resolved the assignment issue [on Lee Feigenbaum - due 2010-09-07].
14:35:15 <LeeF> topic: SELECT * and grouping
14:35:39 <LeeF> Should SELECT * { ?s ?p ?o } GROUP BY ?s be legal, and if so, what does it mean?
14:36:17 <AndyS> no
14:36:26 <AndyS> (to Lee's summary)
14:37:46 <SteveH_> from §10.1 "The syntax SELECT * is an abbreviation that selects all of the variables in a query."
14:37:47 <AxelPolleres> BTW, some side issues arised in the thread for  mail http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0300.html  around SELET *... , 1) SELECT *  expr AS var ... why can't I "extend" SELEC T *   not sure whether to be discussed, 2) "potentially bound" wording for project expressions 3) SELECT *  wording issue
14:38:07 <sandro> lee: what probably makes sense: star stands for legally-projectable-variables, 
14:38:34 <sandro> lee: because including ?p and ?o -- which can't be projected -- doesn't really make sense. 
14:38:44 <AndyS> That's SPARQL 1.0 text - confusing to quote.
14:39:17 <AxelPolleres> in Section 17.2.2 : " or all named variables in the query if SELECT *  used"
14:39:23 <sandro> AndyS: You have to perform the check any way, to make sure people don't use non-key-variables -- a required error check
14:39:36 <Souri> In Oracle SQL, '*' would be illegal in a GROUP BY query (unless GROUP BY includes all the columns)
14:39:49 <sandro> lee: Does anyone think SELECT * { ?s ?p ?o } GROUP BY ?s should be illegal?
14:40:08 <AxelPolleres> whereas section 15.1.1 says "The syntax SELECT * is an abbreviation that  selects all of the variables that could be bound in a query."
14:40:22 <sandro> SteveH_: It seems to me like it should be an error, yes.   to work around the error seems rather convoluted.
14:40:38 <bglimm> I also think it should be an error
14:40:39 <LeeF> AxelPolleres, I think we're trying to decide what this should mean, rather than what the spec says right now :)
14:40:44 <sandro> sandro: SQL?
14:40:48 <MattPerry> I agree with Steve
14:40:58 <AxelPolleres> alrighty, just wanted to point to the current wordings :-)
14:41:00 <pgearon> While easy enough to implement, I believe it should be an error
14:41:19 <sandro> Souri: In oracle, it's an error, "not a GROUP BY expression"
14:41:59 <sandro> lee: several voices for simpler, less useful meaning of star
14:42:06 <sandro> AndyS: what if it's nested?
14:42:26 <LeeF> SELECT * { ... ?x ... { SELECT ?x WHERE { ... ?x ?y ... } } }
14:42:38 <Souri> create table t1 (a int, b int); select * from t1 group by a; returns error "ORA-00979: not a GROUP BY expression", but select * from t1 group by a,b; is okay
14:42:41 <Zakim> -AlexPassant
14:43:15 <Zakim> +??P4
14:43:26 <AlexPassant> Zakim, ?P4 is me
14:43:26 <Zakim> sorry, AlexPassant, I do not recognize a party named '?P4'
14:43:29 <AlexPassant> Zakim, ??P4 is me
14:43:29 <Zakim> +AlexPassant; got it
14:43:53 <sandro> LeeF: I think people know * stands for all the variables potentially in the solution set before grouping.
14:43:57 <SteveH_> exactly, all the variables in the binding set
14:44:30 <sandro> LeeF: So in the nested case, ?y is hidden
14:44:39 <AxelPolleres> but "potentially in the solution" is ambiguous so far, we need a crisp definition
14:45:09 <LeeF> we need consensus on what we want and then a crisp definition :) 
14:45:18 <AxelPolleres> fair enough
14:45:19 <AxelPolleres> :-)
14:45:30 <sandro> SteveH_: not exactly "binding set" but: all the variables in the thing you're operating on at the moment.
14:46:01 <sandro> LeeF: AndyS, do you understand this other point of view?
14:46:29 <sandro> AndyS: I think I understand it, but I don't know it well enough to write the definitions.
14:46:45 <sandro> AndyS: Also, it pre-judges the answer on LET
14:47:11 <sandro> LeeF: We should have a clear proposal before we decide.
14:47:12 <AxelPolleres> I'd hope we *can* make a recursive definition of "visible" variables per pattern, which expresses what most people think... but I am afraid it's easier to write down the def than casting the def into a narrative description...
14:47:18 <SteveH_> I don't see the bearing on "assignment"
14:47:44 <sandro> LeeF: Anyone willing to take the lead on crafting the definition we can look at?
14:47:48 <sandro> AxelPolleres?
14:48:09 <AxelPolleres> Andy, pointer?
14:48:24 <AxelPolleres> can try to expand on that, yes
14:48:25 <AndyS> SteveH_, SELECT * (?a+?b AS ?c)
14:49:03 <LeeF> ACTION: Axel to craft a more rigorous definition of the viewpoint of * as discussed today (* = ?s ?p ?o in 1st example, and * = ?x in 2nd example)
14:49:03 <trackbot> Created ACTION-304 - Craft a more rigorous definition of the viewpoint of * as discussed today (* = ?s ?p ?o in 1st example, and * = ?x in 2nd example) [on Axel Polleres - due 2010-09-07].
14:49:45 <LeeF> q?
14:50:00 <LeeF> topic: function library status
14:51:25 <sandro> lee: last time we went around the group, there was strong support for this.   where were we about minting our own URIs, etc?
14:51:40 <sandro> ivan: Alternative?
14:51:53 <AndyS> q+ to try to remember 
14:52:01 <sandro> lee: reuse XPath/XQuery or possibly RIF URIs.
14:52:05 <LeeF> ack AndyS
14:52:05 <Zakim> AndyS, you wanted to try to remember
14:53:00 <sandro> AndyS: I think it was that we can use F+O URIs, because we have the same semantics (unlike RIF).    Where we have new operations (eg constructors) we may want to generate some.
14:53:09 <sandro> AndyS: eg iri(...)
14:53:24 <sandro> AndyS: or strlang
14:53:58 <sandro> AndyS: They are in query document as built in keywords, no URI for explaining it.
14:54:43 <sandro> LeeF: so to complete our function library we need to (1) give URIs to our builtins, and (2) pick the subset of F&O we need
14:54:56 <sandro> sandro: what about things like "+" that don't have a URI in F&O.
14:55:29 <sandro> AndyS: Yeah, op: is not a namespace, technically.
14:55:45 <sandro> AndyS: those are the terms in the language, like "+"
14:55:57 <AndyS> http://www.w3.org/2009/sparql/wiki/Feature:FunctionLibrary
14:56:12 <sandro> sandro: I think their reasoning had to do with overloading.
14:56:26 <sandro> sandro: i can perhaps look up discussion RIF had with them.
14:56:43 <sandro> AndyS: Also, the op GE which is a combination of GT and EQ.
14:57:02 <sandro> LeeF: This is something we need to figure out....
14:57:03 <LeeF> http://www.w3.org/2009/sparql/wiki/Feature:FunctionLibrary#XQuery_1.0_and_XPath_2.0_Functions_and_Operators
14:57:12 <sandro> LeeF: Is that list a good place to start?
14:57:40 <sandro> AndyS: I made that list by going through and looking for every function I thought was applicable to sparql.
14:57:58 <sandro> AndyS: We might be able to get away without defining URIs, although that would be od.
14:58:03 <sandro> s/od/odd/.
14:58:12 <sandro> AndyS: esp. string operations.
14:58:51 <sandro> LeeF: Anyone think we should NOT be working on this>
14:58:55 <sandro> ... silence ...
14:59:05 <sandro> LeeF: e-mail or telecon>
14:59:15 <sandro> AndyS: email now, then telecon.
14:59:31 <sandro> LeeF: I'll send it to mailing list
14:59:46 <LeeF> ACTION: Lee to start discussion on mailing list about set of functions to include in SPARQL 
14:59:46 <trackbot> Created ACTION-305 - Start discussion on mailing list about set of functions to include in SPARQL  [on Lee Feigenbaum - due 2010-09-07].
15:00:03 <MattPerry> * sorry, got to go -- bye
15:00:15 <sandro> sandro: I wish we could, like RIF, add support for RDF lists by providing a set of list builtins.
15:00:20 <Zakim> -MattPerry
15:00:28 <sandro> AndyS: it's a nice idea, but the list operators wouldn't preserve order.
15:01:05 <sandro> ADJOURN
15:01:08 <Zakim> -LeeF
15:01:08 <ivan> zakim, drop me
15:01:09 <Zakim> -AlexPassant
15:01:09 <Zakim> Ivan is being disconnected
15:01:09 <Zakim> -Ivan
15:01:11 <Zakim> -Souri
15:01:12 <Zakim> -AndyS
15:01:14 <Zakim> -Sandro
15:01:16 <Zakim> -SteveH_
15:01:18 <Zakim> -NicoM
15:01:20 <Zakim> -kasei
15:01:20 <NickH> Bye!
15:01:22 <Zakim> -bglimm
15:01:24 <Zakim> -NickH
15:02:08 <Zakim> -pgearon
15:02:09 <Zakim> SW_(SPARQL)10:00AM has ended
15:02:10 <Zakim> Attendees were NicoM, kasei, Ivan, AndyS, LeeF, Sandro, SteveH_, bglimm, MattPerry, Souri, AlexPassant, NickH, pgearon
16:15:18 <AxelPolleres> AxelPolleres has joined #sparql
16:20:12 <AndyS> PostgreSQL interprets "SELECT *" as any column in the table expression; table expression includes GROUP BY. // sec 7.3.1 & sec 7.2. 
16:22:10 <AndyS> This agrees with SQL 92. sec 7.9 where "T" is a table expression (sec 7.3)
16:23:08 <AndyS> MySQL is a bit unclear to me at the moment and has other uses for * as well.
16:23:49 <SteveH_> and MySQL doesn't error if you try to project ungrouped columns
16:24:35 <AndyS> MySQL prob does not allow SELECT * over group.  Inferred from an example.
16:24:47 <SteveH_> AndyS, so SQL 92 disagrees with oracle?
16:24:49 <AndyS> MySQL promises ordering on GROUP BY doesn't it?
16:24:59 <SteveH_> I don't recall
16:26:32 <AndyS> Yes - Oracle says "Specify the asterisk to select all columns from all tables, views, or materialized views listed in the FROM clause."
16:26:34 <SteveH_> ah, no, I see, SQL'92 does what Souri said on the call
16:27:10 <SteveH_> ""*" is equivalent to a <value
16:27:10 <SteveH_>               expression> sequence in which each <value expression> is a
16:27:10 <SteveH_>               <column reference> that references a column of T and each
16:27:11 <SteveH_>               column of T is referenced exactly once. The columns are ref-
16:27:11 <SteveH_>               erenced in the ascending sequence of their ordinal position
16:27:12 <SteveH_>               within T.
16:27:13 <SteveH_> "
16:27:18 <SteveH_> that matches what Souri said
16:27:45 <AndyS>  T is a table expression
16:28:01 <AndyS>  <table expression> ::=
16:28:01 <AndyS>               <from clause>
16:28:01 <AndyS>               [ <where clause> ]
16:28:01 <AndyS>               [ <group by clause> ]
16:28:01 <AndyS>               [ <having clause> ]
16:28:11 <SteveH_> yes
16:28:27 <AndyS> so include the group.  That's the key differece.  from vs from+group
16:28:47 <SteveH_> right, so it tries to include everything
16:29:09 <SteveH_> but it will fail in the common case, as you can't project non-group-byed columns
16:29:13 <AndyS> So SQL92 includes * use over GROUP BY 
16:29:32 <SteveH_> yes, but it will generally error, unless you've group by-d everything
16:29:37 <AndyS> agree with the non-group by.  It's whether SELECT * .. GROUP BY ?x works.
16:30:03 <SteveH_> sometimes :)
16:30:35 <AndyS> Depends on whether the agree with you.  =>like dinner
16:30:39 <SteveH_> it seems pretty clear to me   foo (a int, b, int) ... group by a+b, will try to project a, b, a+b
16:30:56 <SteveH_> sorry, random clutch of shorthand there
16:31:11 <iv_an_ru> iv_an_ru has joined #sparql
16:31:37 <AndyS> I think SQL-92 says the GROUP BY exposes the grouping cols - does get me a bit lost here - still tracking.
16:32:17 <SteveH_> AndyS, I agree (probably, I'd have to check a lot more, but it sounds right), but the GROUP BY doesn't hide the non-grouped columns
16:33:37 <AndyS> That's unclear to me currently.
16:35:14 <SteveH_> oh, actually §7.7 makes it sound like GROUP BY doesn't add extra colum(s)
16:35:26 <SteveH_> I'd remembered that it did, but I can't find anything saying that
16:35:48 <SteveH_> it just partitions
16:37:21 <SteveH_> it's simpler in SQL'92 because it doesn't all GROUP BY expression
16:37:24 <SteveH_> *allow
16:37:43 <SteveH_> <group by clause> ::=
16:37:43 <SteveH_>               GROUP BY <grouping column reference list>
16:37:55 <SteveH_> etc.
16:38:21 <SteveH_> so you can't "invent" new columns with it anyway
16:38:33 <SteveH_> I don't know what more recent SQL standards say
16:40:58 <AndyS> Expressions don't change this : it's existing cols (that are hidden by being non-key group'ed)
16:43:29 <SteveH_> well, if you don't have expressions it's immaterial, GROUP BY can't add extra columns
16:50:07 <AndyS> It does matter in SELECT * GROUP BY -- what does the * mean?  Is it <grouping column reference list>?
17:03:21 <SteveH_> in * each column is only used once, so it doesn't matter
17:03:40 <SteveH_> why would it be it <grouping column reference list>?
17:05:42 <SteveH_> it says explicitly that * is the references in T
17:06:00 <SteveH_> admittedly sql92 is not the clearest of documents :)
17:07:21 <Zakim> Zakim has left #sparql
17:11:32 <SteveH_> I pasted the relevant test at 17:27, but "each column of T is referenced exactly once", so GROUP BY couldn't change the behaviour of *, even it it did add extra columns, which it doesn't appear that it does
17:12:37 <SteveH_> there is a difference though, SPARQL uses lexical ordering for *, and SQL uses ordinal, but SPARQL doesn't have an ordinal order, so it's a bit academic
18:51:44 <AxelPolleres> AxelPolleres has joined #sparql
19:01:37 <AndyS> AndyS has joined #sparql
19:37:56 <AndyS> AndyS has joined #sparql
19:42:52 <AxelPolleres> AxelPolleres has joined #sparql
20:04:33 <bglimm> bglimm has joined #sparql
20:30:01 <AndyS> AndyS has joined #sparql
21:06:30 <bglimm> bglimm has joined #sparql
21:38:52 <bglimm> bglimm has joined #sparql
22:17:26 <LeeF> LeeF has joined #sparql
22:17:57 <AxelPolleres> AxelPolleres has left #sparql