Chatlog 2010-10-26

From SPARQL Working Group
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

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