IRC log of sparql on 2010-08-31

Timestamps are in UTC.

13:54:34 [RRSAgent]
RRSAgent has joined #sparql
13:54:34 [RRSAgent]
logging to
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]
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]
13:59:16 [NickH]
NickH has joined #sparql
13:59:32 [Zakim]
13:59:45 [NickH]
13:59:53 [NickH]
I am too late for the UK phone number :(
13:59:55 [Zakim]
14:00:00 [ivan]
zakim, dial ivan-voip
14:00:00 [Zakim]
ok, ivan; the call is being made
14:00:04 [Zakim]
14:00:27 [Zakim]
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]
14:03:35 [Zakim]
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:
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]
14:04:26 [Zakim]
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]
14:05:04 [SteveH_]
AndyS, on time doesn't help :(
14:05:06 [Zakim]
14:05:14 [LeeF]
topic: Admin
14:05:17 [AndyS]
Should be better?
14:05:18 [Zakim]
14:05:18 [bglimm]
Ivan, Sandro, will there be more UK phone numbers any time soon?
14:05:26 [LeeF]
PROPOSED: Approve minutes at
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]
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
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]
14:08:39 [LeeF]
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:
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]
14:16:24 [SteveH_]
14:16:30 [ivan]
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]
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]
14:17:55 [AndyS]
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: 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]
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]
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]
14:21:24 [Zakim]
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]
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]
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_]
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_]
14:29:08 [ivan]
14:29:16 [AndyS]
14:29:23 [AxelPolleres]
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]
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]
14:33:07 [AndyS]
14:33:15 [sandro]
14:33:17 [NicoM]
14:33:18 [AlexPassant]
14:33:19 [bglimm]
14:33:21 [MattPerry]
14:33:22 [pgearon]
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_]
14:34:18 [Souri]
14:34:21 [MattPerry]
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]
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 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]
14:43:15 [Zakim]
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]
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]
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]
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]
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]
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]
15:00:28 [sandro]
AndyS: it's a nice idea, but the list operators wouldn't preserve order.
15:01:05 [sandro]
15:01:08 [Zakim]
15:01:08 [ivan]
zakim, drop me
15:01:09 [Zakim]
15:01:09 [Zakim]
Ivan is being disconnected
15:01:09 [Zakim]
15:01:11 [Zakim]
15:01:12 [Zakim]
15:01:14 [Zakim]
15:01:16 [Zakim]
15:01:18 [Zakim]
15:01:20 [Zakim]
15:01:20 [NickH]
15:01:22 [Zakim]
15:01:24 [Zakim]
15:02:08 [Zakim]
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_]
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_]
16:37:43 [SteveH_]
<group by clause> ::=
16:37:43 [SteveH_]
GROUP BY <grouping column reference list>
16:37:55 [SteveH_]
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